Packages, services, and logs / Stage 11 of 13 · step 7 of 8

Cron job isn't running

~15 min

Not running Starting usually ~20 s

Situation

root's schedule has a job: run /usr/local/bin/backup.sh every minute. The script writes the time of its run to /var/backups/heartbeat — that mark shows the job is alive. The mark has never appeared, and nobody has seen any error on screen.

Task

The /usr/local/bin/backup.sh job stays in root's schedule.
cron runs it itself: /var/backups/heartbeat is written when the job runs on schedule. Running the script by hand does not count.

The tools you need are already installed. There's no internet on this machine.

Lab goals

0 of 2

The /usr/local/bin/backup.sh job is still in root's schedule — not checked yet
cron runs the job itself — /var/backups/heartbeat is written when it runs — not checked yet

Hints

0 of 3 open · they open one at a time

Hint 1

Show the solution after 3 failed checks

Services and systemd · picked for this lab

Cron — the task scheduler

Cheat sheet

$_ — insert into the terminal

crontab -e edit your own crontab
crontab -l show the current crontab
*/15 * * * * /usr/local/bin/backup.sh every 15 minutes
systemctl list-timers list systemd timers
journalctl -u backup.service log for a specific job
grep CRON /var/log/syslog what cron ran

cron

A crontab line has five time fields plus a command:

┌── minute (0-59)
│ ┌── hour (0-23)
│ │ ┌── day of month (1-31)
│ │ │ ┌── month (1-12)
│ │ │ │ ┌── day of week (0-7, 0 and 7 = Sun)
│ │ │ │ │
* * * * *  command

bash

crontab -e                        # edit the user's crontab
crontab -l                        # show it
*/15 * * * * /usr/local/bin/backup.sh   # every 15 minutes
0 3 * * *   /usr/local/bin/nightly.sh    # daily at 03:00

System cron lives in /etc/cron.d/, /etc/crontab, /etc/cron.{daily,weekly}.

Other users' crontabs

Personal crontabs live in /var/spool/cron/crontabs/, one file per user. The directory is closed: only root sees the list, and only the owner reads a file.

text

student@ubuntu:~$ ls -ld /var/spool/cron/crontabs
drwx-wx--T 2 root crontab 4096 Oct 21 05:48 /var/spool/cron/crontabs
student@ubuntu:~$ sudo ls -l /var/spool/cron/crontabs
-rw------- 1 deploy crontab 209 Oct 21 05:48 deploy
student@ubuntu:~$ crontab -l -u deploy
must be privileged to use -u
student@ubuntu:~$ sudo crontab -l -u deploy
* * * * * /usr/local/bin/tweak.sh

Every cron run writes to the log: CRON[2086]: (deploy) CMD (/usr/local/bin/tweak.sh) — that is how you find whose job ran.

bash

sudo crontab -e -u deploy                 # fix or delete a line
sudo crontab -l -u deploy | grep -v tweak \
  | sudo crontab -u deploy -              # drop one line
sudo crontab -r -u deploy                 # delete ALL of deploy's jobs

Do not edit the file in /var/spool/cron/crontabs/ by hand: crontab checks the syntax and gives the file the right mode and owner. After crontab -r you get no crontab for deploy: every line is gone, not one.

Schedule and time zone

cron reads the schedule in the machine's time zone: 0 3 * * * means 03:00 by the time date shows. The machine's zone is in timedatectl (timedatectl); on the lab machine it is Etc/UTC.

cron picks up a zone change without a restart. The job 19 21 * * * fired at 21:19 Tokyo time after sudo timedatectl set-timezone Asia/Tokyo:

text

student@node1:~$ cat /tmp/cron-tz.log
Wed Oct 21 21:19:01 JST 2026

A TZ=Asia/Tokyo line in a crontab changes only the job's environment: date inside it prints Tokyo time, but the job still fires by the machine's zone. A server is usually kept in UTC — then the schedule is written in UTC. date shows what a time in another zone is in UTC:

text

student@ubuntu:~$ date -u -d 'TZ="Europe/Moscow" 03:00'
Wed Oct 21 00:00:00 UTC 2026

03:00 in Moscow is 00:00 UTC: the schedule line is 0 0 * * *.

systemd timers

A pair of files: .service (what to do) + .timer (when).

ini

# backup.timer
[Unit]
Description=Nightly backup
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target

bash

sudo systemctl enable --now backup.timer
systemctl list-timers             # timers and next runs
journalctl -u backup.service      # log of a job's execution

The OnCalendar schedule, the service environment and timer troubleshooting are covered in systemd-timers.

A cron job does not run

Cron has a minimal $PATH and no interactive-session environment (aliases, variables from ~/.bashrc) — use absolute paths to commands and files, do not rely on what an ordinary terminal shows.
Logs: journalctl -u cron (Ubuntu 24.04) or grep CRON /var/log/syslog (if cron logs to syslog rather than only to journald).
Every line must end with a newline; a % character in a command means a newline to cron, so it needs escaping (\%).

A timer did not fire while the machine was off

Add Persistent=true — it runs the missed job after the machine comes back up.

I don't know when the next run is

systemctl list-timers --all shows every timer, including inactive ones, with the last and next run times.

A user's crontab job is not visible in the system crontab

crontab -e edits the current user's crontab (stored under /var/spool/cron/crontabs/) — separate from the system files /etc/crontab and /etc/cron.d/*, where an extra field names the user to run the command as. Mixing up the formats is a common reason a job "works for me in crontab -e" but not as a system job.

Cron job isn't running

Situation

Task

Signing in is needed to start the machine

cron

Other users' crontabs

Schedule and time zone

systemd timers

A cron job does not run

A timer did not fire while the machine was off

I don't know when the next run is

A user's crontab job is not visible in the system crontab