Scheduled Automation

Scheduled work is how maintenance actually happens: backups, certificate renewals, cleanup, reports, sync jobs, and recurring checks. The hard part is not writing a command; it is making the job safe, observable, idempotent, and predictable.

Command Examples

systemctl list-timers --all
crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily /var/spool/cron/crontabs
systemctl status cron
journalctl -u cron -b

Example output and meaning:

Cronjobs

Cron runs commands on schedules defined by crontab files. Cronjobs are simple and portable, but they fail quietly when environment, paths, permissions, mail, locking, or host uptime are misunderstood.

Cron jobs do not have the same environment as an interactive shell. Always use absolute paths, explicit environment variables, clear output handling, and predictable working directories.

Common locations:

Crontab field shape:

# minute hour day-of-month month day-of-week command
15 2 * * * /usr/local/sbin/backup-app >>/var/log/backup-app.log 2>&1

Useful schedule examples:

Cron environment:

• SHELL defaults to /bin/sh on many systems, not your login shell.
• PATH is usually minimal.
• HOME and LOGNAME are set from the crontab owner.
• MAILTO controls where command output is mailed if local mail is configured.
• CRON_TZ can set the timezone for schedules in implementations that support it.
• Some implementations support RANDOM_DELAY to spread starts and avoid thundering herds.

Good cronjob pattern:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=ops@example.com

15 2 * * * flock -n /run/backup-app.lock /usr/local/sbin/backup-app >>/var/log/backup-app.log 2>&1

Cronjob design rules:

• Put complex logic in a script under version control; keep the crontab line short.
• Use absolute paths for commands, config files, logs, and working directories.
• Use flock or a service-level lock so slow runs do not overlap.
• Make the job idempotent so manual reruns are safe.
• Send output somewhere monitored. Silence is only safe if a separate monitor checks last success time.
• Check exit codes and fail hard when a required command fails.
• Use a dedicated user instead of root when possible.
• Treat secrets carefully: prefer root-readable config files, environment files with tight permissions, or workload identity. Do not paste long-lived credentials into crontabs.
• Think about timezone and DST. Jobs scheduled during skipped or repeated local times can behave surprisingly.

Cron versus anacron:

Cron does not know whether a service dependency is ready. If a job needs networking, a mounted volume, or a database, the script must check that dependency or the job should usually be a systemd timer/service pair.

systemd Timers

systemd timers pair a .timer unit with a .service unit. They are often better for system-level automation because they integrate with dependencies, logs, missed-run handling, resource controls, and service isolation.

systemctl cat apt-daily.timer
systemctl status apt-daily.timer
journalctl -u apt-daily.service -b

Minimal timer pair:

# /etc/systemd/system/backup-app.service
[Unit]
Description=Backup app data

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-app
User=backup
Group=backup

# /etc/systemd/system/backup-app.timer
[Unit]
Description=Run app backup daily

[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true
RandomizedDelaySec=15m

[Install]
WantedBy=timers.target

Persistent=true lets a timer catch up after the machine was off at the scheduled time. RandomizedDelaySec= spreads jobs so many hosts do not all start at once.

Job Safety

Operational automation should handle:

• idempotency,
• locking to prevent overlapping runs,
• timeout behavior,
• clear logs,
• failure alerts,
• safe retries,
• least-privilege execution,
• secrets handling,
• rollback or cleanup on partial failure.

For backups and transfer jobs, see Linux Backup and File Transfer for rsync, scp, snapshot consistency, and restore checks.

Troubleshooting Flow

1. Confirm the schedule is loaded.
2. Confirm the job ran at the expected time.
3. Check logs for the service or cron daemon.
4. Reproduce with the same user and environment.
5. Check working directory, PATH, permissions, and shell.
6. Check locks and stale pid files.
7. Confirm the job is safe to rerun manually.

Cron-specific checks:

crontab -l
sudo crontab -l -u <user>
sudo grep -R '^[^#]' /etc/crontab /etc/cron.d 2>/dev/null
sudo run-parts --test /etc/cron.daily
journalctl -u cron -b
grep CRON /var/log/syslog

If a cronjob works manually but not in cron, reproduce the cron environment:

sudo -u <user> env -i SHELL=/bin/sh HOME=/home/<user> PATH=/usr/bin:/bin /usr/local/sbin/job

Common cron failures:

Study Cards

References

• crontab(5)
• anacrontab(5)
• systemd.timer
• systemd.service
• Debian Reference: scheduled tasks