-1

I've set up an Ubuntu server and deleted a user Ubuntu that happened to be there after imaging.

There are no crontabs for root or my user. Does that mean nothing from /etc/crontab.* runs? Will I have to call those cron jobs from a root crontab?

  • There should be the system-wide crontab, /etc/crontab; this is not root's crontab, it's the system-wide crontab (and has a slightly different format). The scripts in /etc/cron.hourly, /etc/cron.daily etc. are run from the system-wide crontab using run-parts. – AlexP Nov 2 '17 at 0:56
1

This is documented in the cron(8) manpage (when you read that, consider that anything Debian-specific also applies to Ubuntu). In particular:

cron searches its spool area (/var/spool/cron/crontabs) for crontab files (which are named after accounts in /etc/passwd); crontabs found are loaded into memory. Note that crontabs in this directory should not be accessed directly — the crontab command should be used to access and update them.

cron also reads /etc/crontab, which is in a slightly different format (see crontab(5)). In Debian, the content of /etc/crontab is predefined to run programs under /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. This configuration is specific to Debian, see the note under DEBIAN SPECIFIC below.

Additionally, in Debian, cron reads the files in the /etc/cron.d directory. cron treats the files in /etc/cron.d as in the same way as the /etc/crontab file (they follow the special format of that file, i.e. they include the user field). However, they are independent of /etc/crontab: they do not, for example, inherit environment variable settings from it.

The default /etc/crontab is as follows:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

(with additional support for anacron thrown in).

Thus even if no users have user-specific crontabs, there are still a number of places cron jobs can be specified on Debian derivatives. They are handled in a variety of ways, as described above; anything in /etc/cron.d will be interpreted directly by cron, but the contents of /etc/cron.monthly, weekly, daily and hourly are run by the corresponding instruction in /etc/crontab, or by anacron if that’s installed (for daily, weekly and monthly jobs).

The reflects the various roles of cron jobs. /etc/cron.d allows packages to drop cron jobs with cron specifiers and have them run. /etc/cron.monthly etc. allow packages and system administrators to drop scripts or binaries without cron specifiers and have them run at some regular interval, with no need for precise control over the exact moment at which they run. Per-user crontabs allow users to define their own jobs, with explicit validation (using the crontab command) to ensure that the format is valid before the system attempts to use them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.