TL;DR
After updating
/etc/crontabs/root
, putting an emptycron.update
file in the/etc/crontabs
will update directory's last modification, cron daemon will reload jobs from the files in the/etc/crontabs
andcron.update
file will be deleted.
A bit more about why and how
In a situation where container's crontabs directory (/etc/crontabs
) is mounted from a host, just editing file that container sees as a /etc/crontabs/root
file outside of a container will not trigger a cron daemon to reload jobs.
Looking at the busybox source code, there is a comment saying
The file 'cron.update' is checked to determine new cron jobs. The directory is rescanned once an hour to deal with any screwups.
Additionally, the code is checking if the /etc/crontabs
directory's last modification time changed which triggers a job update. To update last modification time of a directory, something should be added, removed or renamed inside that directory (excluding subdirectories). For example, adding a random file put into the /etc/crontabs
will update last modification time which will trigger reloading jobs in the next cycle (the next minute). This is good, since container doesn't have to be restarted for new jobs to take effect. The downside is a lack of feedback that this really happened.
So, instead of a random file, a file named cron.update
can be used to get a confirmation that jobs have been reloaded. File is used by crontab to notify cron daemon that a cron file has been updated and a cron daemon will delete cron.update
once it reloads the jobs, meaning that if the file is gone, jobs are reloaded. Crontab writes the changed file name into the cron.update
file, but since adding a file updates directory's last modification time, an empty file will do the trick.
Top comments (0)