Admin: New server guide

2026-04-12T20:01:50Z

New server guide

New page

== Cron Jobs and Task Scheduling ==

This guide covers essential task scheduling methods on Linux systems, including `cron`, `systemd timers`, and the `at` command. Automating repetitive tasks is crucial for efficient server administration, from backups and log rotation to software updates and custom script execution.

== Prerequisites ==

* A Linux server with root or sudo privileges.
* Basic understanding of the Linux command line.
* Familiarity with text editors like `nano` or `vim`.
* Internet access for package installation if needed (though these tools are typically pre-installed).

== Understanding Task Scheduling ==

Task scheduling allows you to execute commands or scripts automatically at predefined times or intervals. This is fundamental for maintaining server health, security, and performance without manual intervention.

=== Cron Jobs ===

`cron` is the traditional and most widely used task scheduler on Unix-like systems. It uses a configuration file called a "crontab" to define scheduled jobs.

==== How Cron Works ====

The `cron` daemon (`crond`) runs in the background, checking the crontab files every minute to see if any jobs need to be executed.

==== Crontab Syntax ====

A crontab entry consists of five time-and-date fields, followed by the command to be executed.

<pre>
* * * * * command_to_execute
- - - --- --------------------
| | | | |
| | | | +----- Day of week (0 - 7) (Sunday=0 or 7)
| | | +------- Month (1 - 12)
| | +--------- Day of month (1 - 31)
| +----------- Hour (0 - 23)
+------------- Minute (0 - 59)
</pre>

* An asterisk (`*`) means "every".
* Specific numbers can be used for exact times.
* Ranges can be specified using hyphens (e.g., `1-5` for Monday to Friday).
* Lists can be used with commas (e.g., `0,15,30,45` for every 15 minutes).
* Step values can be used with a slash (e.g., `*/15` for every 15 minutes).

==== Managing Your Crontab ====

You can edit your user's crontab with the `crontab` command.

# Open your crontab for editing:
<pre>
crontab -e
</pre>

# To list your current cron jobs:
<pre>
crontab -l
</pre>

# To remove all your cron jobs (use with extreme caution):
<pre>
crontab -r
</pre>

==== Examples of Cron Jobs ====

* **Run a script every day at 3:00 AM:**
<pre>
0 3 * * * /path/to/your/script.sh
</pre>

* **Run a backup script every Monday at 1:00 AM:**
<pre>
0 1 * * 1 /path/to/backup_script.sh
</pre>

* **Run a cleanup script every hour:**
<pre>
0 * * * * /path/to/cleanup_script.sh
</pre>

* **Run a script at 9:00 AM and 5:00 PM every weekday:**
<pre>
0 9,17 * * 1-5 /path/to/daily_report.sh
</pre>

==== Redirecting Output ====

By default, `cron` emails the output (stdout and stderr) of jobs to the user who owns the crontab. To prevent this or to log output to a file:

* **Discard all output:**
<pre>
* * * * * /path/to/your/script.sh > /dev/null 2>&1
</pre>
(`> /dev/null` redirects standard output, `2>&1` redirects standard error to standard output).

* **Log output to a file:**
<pre>
* * * * * /path/to/your/script.sh >> /var/log/my_script.log 2>&1
</pre>
( `>>` appends to the log file).

==== System-wide Cron Jobs ====

System administrators can place scripts in directories like `/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/`, and `/etc/cron.monthly/`. Scripts placed in these directories will be executed automatically by the `cron` daemon at the corresponding intervals.

=== Systemd Timers ===

`systemd` timers are a more modern and flexible alternative to `cron`, integrated into the `systemd` init system. They offer more precise control over scheduling and better logging integration.

==== How Systemd Timers Work ====

`systemd` timers consist of two unit files: a `.service` file defining the task to be run, and a `.timer` file defining when the task should run.

==== Creating a Systemd Timer ====

Let's create a timer to run a script every 10 minutes.

1. **Create the service file:**
Create a file named `my-task.service` in `/etc/systemd/system/`.

<pre>
# /etc/systemd/system/my-task.service
[Unit]
Description=My Custom Task

[Service]
Type=oneshot
ExecStart=/path/to/your/script.sh
</pre>

2. **Create the timer file:**
Create a file named `my-task.timer` in `/etc/systemd/system/`.

<pre>
# /etc/systemd/system/my-task.timer
[Unit]
Description=Run My Custom Task every 10 minutes

[Timer]
OnBootSec=10min
OnUnitActiveSec=10min
AccuracySec=1min

[Install]
WantedBy=timers.target
</pre>

* `OnBootSec`: The time to wait after boot before activating the timer.
* `OnUnitActiveSec`: The time to wait after the service unit was last activated.
* `AccuracySec`: Allows `systemd` to synchronize timers to save power.

3. **Reload systemd, enable, and start the timer:**

# Reload systemd to recognize new unit files:
<pre>
sudo systemctl daemon-reload
</pre>

# Enable the timer to start on boot:
<pre>
sudo systemctl enable my-task.timer
</pre>

# Start the timer immediately:
<pre>
sudo systemctl start my-task.timer
</pre>

4. **Check the status of the timer:**

<pre>
sudo systemctl status my-task.timer
</pre>

# To see when it's scheduled to run next:
<pre>
sudo systemctl list-timers
</pre>

==== Systemd Timer Calendar Events ====

You can also use `OnCalendar` for more cron-like scheduling:

<pre>
# /etc/systemd/system/my-calendar-task.timer
[Unit]
Description=Run My Task on a Calendar Schedule

[Timer]
OnCalendar=*-*-* 03:00:00
# This runs daily at 3:00 AM.
# You can use more complex patterns like:
# OnCalendar=Mon,Tue,Wed,Thu,Fri *-*-* 09:00:00 (weekdays at 9 AM)
# OnCalendar=*-*-* *:00:00 (every hour on the hour)

[Install]
WantedBy=timers.target
</pre>

=== The `at` Command ===

The `at` command schedules commands to be executed once at a specified time in the future. It's useful for one-off tasks.

==== How to Use `at` ====

1. **Install `at` (if not already installed):**
On Debian/Ubuntu:
<pre>
sudo apt update
sudo apt install at
</pre>
On CentOS/RHEL:
<pre>
sudo yum install at
</pre>

2. **Schedule a job:**
Use `at` followed by the desired time. You'll then be prompted to enter commands. Press `Ctrl+D` to exit.

# Schedule a command to run tomorrow at 10:30 AM:
<pre>
at 10:30 AM tomorrow
# at> echo "This is a one-time job." | mail -s "At Job" your_email@example.com
# at> (Press Ctrl+D)
</pre>

# Schedule a command to run in 2 hours:
<pre>
at now + 2 hours
# at> /path/to/one_off_script.sh
# at> (Press Ctrl+D)
</pre>

==== Managing `at` Jobs ====

* **List pending `at` jobs:**
<pre>
atq
</pre>

* **Remove a pending `at` job:**
Use `atq` to find the job number, then `atrm` to remove it.
<pre>
atrm 5 # Removes job number 5
</pre>

==== `at` Permissions ====

The `at` command's behavior is controlled by `/etc/at.allow` and `/etc/at.deny`.
* If `/etc/at.allow` exists, only users listed in it can use `at`.
* If `/etc/at.allow` does not exist but `/etc/at.deny` does, users not listed in `/etc/at.deny` can use `at`.
* If neither file exists, `root` can use `at` and potentially other users depending on system configuration.

== Troubleshooting ==

* **Cron job not running:**
* Check if the `cron` daemon is running: `sudo systemctl status cron` (or `crond`).
* Verify the crontab syntax for errors.
* Ensure the script has execute permissions (`chmod +x /path/to/your/script.sh`).
* Check the `syslog` or `cron` logs (e.g., `/var/log/syslog`, `/var/log/cron`) for error messages.
* Ensure the script's path is absolute and any commands within it are in the system's `PATH` or use their absolute paths.

* **Systemd timer not running:**
* Check timer status: `sudo systemctl status my-task.timer`.
* Check service status: `sudo systemctl status my-task.service`.
* Examine journal logs: `sudo journalctl -u my-task.service`.
* Ensure `systemd daemon-reload` was run after creating/modifying unit files.

* **`at` command not working:**
* Check `/etc/at.allow` and `/etc/at.deny` to ensure your user is permitted.
* Verify the `atd` daemon is running: `sudo systemctl status atd`.

== Conclusion ==

Mastering task scheduling with `cron`, `systemd timers`, and `at` is a fundamental skill for any Linux system administrator. `cron` remains a reliable choice for many, while `systemd timers` offer advanced features and integration. The `at` command is perfect for ad-hoc, one-time tasks. Choosing the right tool depends on your specific needs for flexibility, precision, and integration.

[[Category:Optimization]]
[[Category:System Administration]]
[[Category:Linux]]

{{Exchange Box}}

Cron Jobs and Task Scheduling - Revision history

Admin: New server guide