For the record I'm going to suggest using /etc/cron.d/
. Only root can write files here but the entries can be configured to run as any user (without need for sudo
at run-time). This example defines the task named my_webadmin
that will execute /usr/local/bin/tidy_logfiles
as the user webadmin
every Sunday at midnight:
echo '0 0 * * 0 webadmin /usr/local/bin/tidy_logfiles' >/etc/cron.d/my_webadmin
An important part is that the my_webadmin
should be unique to you (not necessarily unique for the run, though) because any installation package can also write files here and you want to avoid a clash. Having this uniqueness constraint, you can update my_webadmin
with a simple overwrite, since you know it's "yours" and won't contain entries for anyone/anything else.
Furthermore, with this approach it becomes trivial to remove the cron entry
rm -f /etc/cron.d/my_webadmin
Possibly outside the scope of your question, but if you have remote access to the root account (or via sudo
) you can even provision remotely,
echo '0 0 * * 0 webadmin /usr/local/bin/tidy_logfiles' > ~/webadmin.cron
scp -p ~/webadmin.cron root@remote_host:/etc/cron.d/my_webadmin
or,
echo '0 0 * * 0 webadmin /usr/local/bin/tidy_logfiles' |
ssh -q root@remote_host 'cat >/etc/cron.d/my_webadmin'
and remove the provisioning,
ssh -nq root@remote_host rm -f /etc/cron.d/my_webadmin
(Note that in many cases you cannot provide root's password for the scp
/ssh
commands because the root account is constrained to prevent password-based logins. Instead you need to have set up public/private key certificates. Also, by implication the local account (whatever it is) will have full root access to the remote server.)
/etc/cron.d
? If so, put your script in there using a name unique to your application/etc/crontab
, files in/etc/cron.d/
have an extra field for the username, immediately after the schedule spec. e.g.* * * * * username /path/to/script
. Seeman 5 crontab
and search forSYSTEM CRON
.