Cron jobs

Basic task scheduling on Unux based systems

More here about the commands as well as cron expressions: https://www.doabledanny.com/cron-jobs-on-mac

Check your cron expression: https://crontab.guru/

Understanding Job Scheduling: cron, crontab, and launchd

Core Components

1. cron (The Traditional Unix Scheduler)

What it is:

• A time-based job scheduler found on Unix-like systems (Linux, BSD, macOS)

• A daemon process (/usr/sbin/cron or /usr/sbin/crond) that runs continuously in the background

• Checks every minute for scheduled jobs to run

• Reads schedule files and executes commands at specified times

Where it reads from:

/var/spool/cron/crontabs/username  # Individual user crontabs (Debian/Ubuntu)
/var/spool/cron/username           # Individual user crontabs (Red Hat/CentOS)
/etc/crontab                       # System-wide crontab
/etc/cron.d/                       # Additional system cron files
/etc/cron.hourly/                  # Scripts run hourly
/etc/cron.daily/                   # Scripts run daily
/etc/cron.weekly/                  # Scripts run weekly
/etc/cron.monthly/                 # Scripts run monthly

---

2. crontab (The Configuration Tool and File Format)

What it is:

• Both a command-line tool AND the file format used by cron

• Each user has their own crontab file

• Contains the schedule and commands in a specific syntax

Common commands:

crontab -e     # Edit your personal crontab
crontab -l     # List your current cron jobs
crontab -r     # Remove all your cron jobs
crontab -u username -e  # Edit another user's crontab (requires root)

File format:

For user crontabs (edited with crontab -e):

# minute hour day month weekday command
0 9 * * * /path/to/script.py
30 14 * * 1-5 /home/user/backup.sh

For system-wide /etc/crontab:

# minute hour day month weekday user command
0 9 * * * root /path/to/script.py
*/15 * * * * www-data /var/www/cleanup.sh

Format explained:

• minute: 0-59

• hour: 0-23 (24-hour format)

• day: 1-31

• month: 1-12

• weekday: 0-7 (0 and 7 are Sunday, 1 is Monday)

• user: (only in /etc/crontab and /etc/cron.d/*) which user runs the command

• command: the script or command to execute

Special syntax:

* * * * *     # Every minute
*/5 * * * *   # Every 5 minutes
0 0 * * *     # Daily at midnight
0 0 * * 0     # Weekly on Sunday at midnight
0 0 1 * *     # Monthly on the 1st at midnight
@reboot       # Run once at startup
@daily        # Run once a day (same as 0 0 * * *)
@hourly       # Run once an hour (same as 0 * * * *)

Common practices:

# Redirect output to avoid email notifications
0 9 * * * /path/to/script.py > /dev/null 2>&1

# Log output to a file
0 9 * * * /path/to/script.py >> /var/log/myscript.log 2>&1

# Set environment variables
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 9 * * * /path/to/script.py

---

3. launchd (macOS-Specific Alternative)

What it is:

• Apple's replacement for cron and other Unix init systems

• The first process (PID 1) on macOS

• Manages services, daemons, and scheduled tasks

• Actually starts and manages the cron daemon when cron is used on macOS

Why it matters for macOS users:

• Apple has deprecated cron in favor of launchd

• cron still works but may require Full Disk Access permissions on modern macOS

• launchd offers advantages: runs missed jobs, better logging, macOS security integration

• If developing primarily for macOS, learn launchd; if targeting Linux servers, focus on cron

The relationship on macOS:

launchd (PID 1)
    ├── Manages cron daemon (/usr/sbin/cron)
    │   └── cron reads crontab files and executes jobs
    └── Manages its own scheduled jobs via .plist files

---

launchd Job Types (macOS Only)

LaunchDaemons (System-wide)

• Location: /Library/LaunchDaemons/

• Run as root or specified user

• Start at boot time

• For system-level services

LaunchAgents (User-level)

• Location: ~/Library/LaunchAgents/ (per-user) or /Library/LaunchAgents/ (all users)

• Run as the logged-in user

• Start at user login

• For user-specific tasks

Example scheduled task:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.backup</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/backup.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
</dict>
</plist>

Common launchd commands:

launchctl load ~/Library/LaunchAgents/com.user.backup.plist
launchctl unload ~/Library/LaunchAgents/com.user.backup.plist
launchctl list
launchctl start com.user.backup

---

Practical Tips

Debugging cron jobs:

# Check if cron daemon is running
ps aux | grep cron
systemctl status cron      # systemd-based systems
service cron status        # SysV init systems

# View cron logs
tail -f /var/log/syslog    # Debian/Ubuntu
tail -f /var/log/cron      # Red Hat/CentOS
journalctl -u cron         # systemd systems

# Test your cron timing
# Use https://crontab.guru to verify your schedule syntax

Common pitfalls:

• Cron jobs run with minimal environment variables (PATH, HOME, etc.)

• Always use absolute paths in cron commands

✅ Use absolute paths for everything
0 9 * * * cd /home/user/myproject && /usr/bin/python3 script.py
✅ Or make your script handle paths properly
0 9 * * * /usr/bin/python3 /home/user/myproject/script.py
✅ Use absolute paths for output files
0 9 * * * /usr/bin/python3 /home/user/script.py >> /var/log/myscript.log 2>&1

In your script itself:

# ❌ Bad: relies on current directory
with open('config.json') as f:
    config = json.load(f)

# ✅ Good: use absolute paths or script-relative paths
import os
script_dir = os.path.dirname(os.path.abspath(__file__))
config_path = os.path.join(script_dir, 'config.json')
with open(config_path) as f:
    config = json.load(f)

• Remember that cron doesn't run missed jobs if the system was off. If your computer or server is turned off or asleep at the scheduled time, cron simply skips that job. It doesn't "catch up" when the system comes back online.

• Email notifications are sent by default unless output is redirected

What do 1>&2 or 2>&1 mean?

• Answer: https://dev.to/iggredible/what-does-2-1-mean-290

• TL;DR: *2>&1 means redirect the stderr (>2) to where stdout is being redirected to (&1)*

Whenever you use this kind of cron expression:

• For example: ***** python3 main.py>> output.log 2>&1 , the >> will redirect the output to a file (in this case output.log but can be any file like .txt or else). 2>&1 will make sure that not only stdout gets redirected to that file but also stderr will go there to.

• Note: each print statement in your Python code (or e.g. Golang’s fmt.Println()) will be logged because print() writes to stdout.

• If you want to be more selective about what gets logged, you could:

  1. Use Python's logging module instead of print()

  2. Remove the redirection from the bash script

  3. Or redirect only specific parts of the output