amazonlinux
[Package Request] - Cronie
What package is missing from Amazon Linux 2022? Please describe and include package name. cronie cronie-anacron
Is this an update to existing package or new package request? New package request
Is this package available in Amazon Linux 2? If it is available via external sources such as EPEL, please specify. Yes
Any additional information you'd like to include. (use-cases, etc) Although cronie is listed in the package lists for Amazon Linuz 2022/2023 the package is missing when we deploy an instance with this AMI. If we build an AMI using EC2 Image Builder I can see that the package is present at the start of the build, but later it seems to get removed. I can see this in /var/log/dnf.log:
2023-03-07T12:35:40+0000 DDEBUG Command: yum remove -y cronie 2023-03-07T12:35:40+0000 DDEBUG Installroot: / 2023-03-07T12:35:40+0000 DDEBUG Releasever: 2022.0.20221103 2023-03-07T12:35:40+0000 DEBUG cachedir: /var/cache/dnf 2023-03-07T12:35:40+0000 DDEBUG Base command: remove 2023-03-07T12:35:40+0000 DDEBUG Extra commands: ['remove', '-y', 'cronie']
I was able to install cronie-1.5.7-1.amzn2023.0.2.x86_64 and cronie-anacron-1.5.7-1.amzn2023.0.2.x86_64 on AL 2023.0.20230308 without problem.
Yes, I'm installing it via user-data at the moment, but shouldn't it come with the AMI by default? It did on Linux2 at least... Also, I can't add it as a component in Image Builder because it uninstalls it at the end, which is weird.
Amazon Linux 2023 has migrated internal recurring tasks to systemd timers, and we generally recommend that approach. That's why there's no cron daemon running by default. However, as pointed out above, it's still available.
Also, I can't add it as a component in Image Builder because it uninstalls it at the end, which is weird.
I can confirm that. EC2 Image Builder doesn't yet officially support AL2023, but I'll follow up with the team to make sure they're aware of this.
Yes, I'm installing it via user-data at the moment, but shouldn't it come with the AMI by default? It did on Linux2 at least... Also, I can't add it as a component in Image Builder because it uninstalls it at the end, which is weird.
It's one of the components we have decided not to include in the AMIs in AL2023 as the same (in fact, better) functionality is provided by systemd.
The functionality of systemd timers (see https://www.freedesktop.org/software/systemd/man/systemd.timer.html ) is a superset of what you could do with cron, including powerful functionality around timing accuracy and resource control. Timer accuracy and jitter can be important to avoid thundering herd problems in larger clusters of systems.
If we added a section to the documentation about the package differences in AMIs, and a section about migrating to systemd timers in the AL2->AL2023 part of the documentation, would that be helpful? It sounds like this was more of a surprise here than we intended it to be, so I would like to work out how we could have made it not a surprise.
If we added a section to the documentation about the package differences in AMIs, and a section about migrating to systemd timers in the AL2->AL2023 part of the documentation, would that be helpful? It sounds like this was more of a surprise here than we intended it to be, so I would like to work out how we could have made it not a surprise.
Yes, it would definitely. I tried searching for something like this in the docs but couldn't find anything, and what made it more confusing was that I found some docs mentioning that Linux 2022/2023 came with cronie packages installed.
I can confirm that. EC2 Image Builder doesn't yet officially support AL2023, but I'll follow up with the team to make sure they're aware of this.
Letting us add cronie as a component in Image Builder would also be appreciated, even tho systemd is the recommended way of doing it now, for our use case it would probably be better to stick with cron for now since we support a stack with multiple versions of Amazon Linux (Linux 1, Linux 2 and Linux 2022 now) using the same user-data scripts and none of our jobs are that time sensitive or critical.
We also need a crontab, at least for our legacy software. We're transitioning from AL2 and our software package requires crontab.
So, I installed "cronie" in our ImageBuilder script but then it gets automatically removed before the AMI is created. Is there a way to turn this off? How do we build an AL2023 AMI with "cronie" pre-installed?
@rnhurt I think our hack-y workaround is going to be installing it in the user-data script on boot :\
We use Ansible to build our AMIs, so I just removed the "crontab_installed" file at the end of my scripts. It is indeed hacky, but it works. 😁
# AL2023 uses "systemd" and has decreed that cron is no longer a valid way to manage tasks
# and removes it if you try to install it.
# However, we currently use the "whenever" Ruby Gem which relies on cron. This hack prevents
# the SSM install script from removing it after it's finished with it's tasks.
- name: prevent AL2023 from uninstalling cronie
shell: rm /tmp/imagebuilder_service/crontab_installed
@rnhurt Thank you for the solution. It works perfectly. I just changed so ansible-lint is happy :)
# AL2023 uses "systemd" and has decreed that cron is no longer a valid way to manage tasks
# and removes it if you try to install it.
# However, we currently use the "whenever" Ruby Gem which relies on cron. This hack prevents
# the SSM install script from removing it after it's finished with it's tasks.
- name: Prevent AL2023 from uninstalling cronie
file:
path: /tmp/imagebuilder_service/crontab_installed
state: absent
I see how systemd timers replace system cron, but was is there a replacement for user-level crontabs?
Note that cronie is still fully supported. If you need it, for compatibility, convenience, or other reasons, it's as close as dnf install cronie. We don't install it by default because it's not used for anything by default.
> # AL2023 uses "systemd" and has decreed that cron is no longer a valid way to manage tasks
> # and removes it if you try to install it.
That's not an accurate statement. As noted above, we don't install cronie because we don't use it. You are free to install it; it's in the repositories and fully supported. It's been reported in the past that the EC2 ImageBuilder service is removing cronie during the image build process. That's a bug that's been reported to them previously. I'll follow up to see about getting this fixed.
just a side note regarding cronie vs systemd: https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html#cron
just a side note regarding cronie vs systemd: https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html#cron
That sentence reads wrong:
In AL2023, we use systemd timer units and cronie extensively
How can cronie be extensively used if it is not installed?
@nmeyerhans may I ask, were there any updates? it would be great to inform customers regarding cronie package caveat here, it seems that Security best practices for EC2 Image Builder is also outdated, if I understand correctly this exactly where we have this check on post-build phase:
SERVICE_ROOT_WORKING_DIR="/tmp/imagebuilder_service"
function uninstall_crontab() {
os_type="$(get_os_type)"
case ${os_type} in
'amzn')
echo "Uninstalling cronie package"
sudo yum remove -y cronie
;;
esac
}
if [[ -f ${SERVICE_ROOT_WORKING_DIR}/crontab_installed ]] ; then
echo "Uninstalling crontab installed by image builder"
uninstall_crontab
fi
We seem to be having a similar problem which has brought me here.
In our image builder we have the following line: - yum install -y cronie # Crontab
From the image builder logs, we see that cronie package is installed successfully.
However, when we launch an ec2 instance from the resulting AMI, cronie/crontab is not installed. Checking the logs in the resulting instance, we see the install msgs, but much further down in the /var/log/dnf.rpm.log as last step we see:
2024-07-15T16:34:49+0000 SUBDEBUG Erase: cronie-1.5.7-1.amzn2023.0.2.x86_64
2024-07-15T16:34:49+0000 INFO Removed "/etc/systemd/system/multi-user.target.wants/crond.service".
2024-07-15T16:34:49+0000 SUBDEBUG Erase: cronie-anacron-1.5.7-1.amzn2023.0.2.x86_64
From the convo above, it appears the SSM is uninstalling cronie. This seems very weird as we explicitly installed this package.
Any advice what to do here? It appears that something is making unrequested changes inside our images....
@kevGalway you may try putting a flag to prevent cronie removal, or installing it at boot time in cloud-init script
@kevGalway I ran into the same problem and solved it by removing the "crontab_installed" file at the end of my AMI build.
https://github.com/amazonlinux/amazon-linux-2023/issues/300#issuecomment-1713520079
Disappointed. You should solve this internally in Amazon for AMI Image Builder to not uninstall cronie behind the scenes if we install it. The issue is not Amazon Linux per se but AMI Image Builder. This issue should stay open unless we can file this bug elsewhere and won't be ignored. So people can find this issue as not solved and can still use hackish workaround mentioned in the comments.
Unfortunately we (Amazon Linux) don't own EC2 Image Builder, you should report the issue to them. I'll also try to poke internally see if I can find a contact
Noticed that in my system location to file is diffrent, but solved deletion with simple shell command
find / -type f -iname crontab_installed -delete
Eero
Noting from the Image Builder side we've pushed a change to make this easier by exposing two environment variables, WORKING_DIRECTORY and IMAGE_BUILDER_DIRECTORY. The following component will remove the crontab_installed file:
schemaVersion: 1.0
phases:
- name: build
steps:
- name: ImageBuilderDirectory
action: ExecuteBash
inputs:
commands:
- printenv IMAGE_BUILDER_DIRECTORY
- name: DeleteFile
action: DeleteFile
if:
fileExists: '{{ build.ImageBuilderDirectory.outputs.stdout }}/crontab_installed'
inputs:
- path: '{{ build.ImageBuilderDirectory.outputs.stdout }}/crontab_installed'
@austoonz weird that component actually results in a 404 trying to delete /etc/imagebuilder/crontab_installed
Specifically deleting /tmp/imagebuilder_service/crontab_installed works though (AL 2023).
Looks like IMAGE_BUILDER_DIRECTORY reports /tmp/imagebuilder instead of /tmp/imagebuilder_service?
Ack - thank you! Found another big. I'll circle back when that's resolved.