/etc/crontabs/root, putting an empty
cron.updatefile in the
/etc/crontabswill update directory's last modification, cron daemon will reload jobs from the files in the
cron.updatefile will be deleted.
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.