Services and logs

Boot, reboot, and scheduled work

Know when a reboot is necessary and choose between cron and systemd timers for repeated background work.

8 minute lesson

~~~

A reboot stops every process on the machine. Do not use it as the first response to a service problem.

Before rebooting a remote server, check why the reboot is needed, who is connected, and whether important work is running:

test -f /run/reboot-required && cat /run/reboot-required.pkgs
who
systemctl --failed

Confirm that services start automatically, backups are current, and you have console access if SSH does not return.

Reboot with:

sudo systemctl reboot

Keep your current SSH session open until the command disconnects it. After the machine returns, verify the new boot, failed units, listening ports, and application health.

Schedule repeated work deliberately

Cron is a small, widely available scheduler. Edit your user crontab with:

crontab -e

This entry runs a backup script every day at 02:15:

15 2 * * * /home/ada/bin/backup-notes >> /home/ada/log/backup.log 2>&1

Scheduled jobs run with a smaller environment than your interactive shell. Use absolute paths, set required variables explicitly, and collect both output and errors.

Test the command manually with the same user before scheduling it.

When a systemd timer is a better fit

Systemd timers pair scheduling with a service unit. They provide journal logs, dependency ordering, resource controls, and options for missed runs.

Inspect existing timers with:

systemctl list-timers --all

Use a timer when the job is part of system operation and you want the same service management and logging as other units. Cron remains fine for a small personal job.

Avoid overlapping runs

A backup that takes longer than its interval can start twice. Design the job to detect or prevent overlap, and make repeated execution safe when possible.

After scheduling, verify that the job ran and produced the expected artifact. A scheduler reporting success only proves that it launched the command.

Try this: write a schedule for a harmless command in a disposable environment. Include an absolute command path, an output destination, and a way to verify the result.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →