Home
Linux Systemd
systemd v240+ Standard•OnCalendar, OnBootSec, Persistent & Jitter

Linux Systemd (.timer & .service) Unit Generator

Build systemd timer and companion service unit files with OnCalendar scheduling, OnBootSec intervals, Persistent execution, and random delays.

Presets:
Schedule Evaluation:Calendar trigger active: "*-*-* 02:30:00" • Catch-up enabled (executes immediately upon boot if system was down when scheduled) • Adds random jitter up to 15m to prevent cluster load spikes
Input
Unit Naming & Identification/etc/systemd/system/
.timer
Trigger Mechanism
Companion Service ExecutionType=oneshot
Sandboxing & Security HardeningLinux Namespaces
#!/usr/bin/env bash
# ==============================================================================
# Linux Systemd Unit Installer: db-backup.timer & db-backup.service
# Auto-generated by ToolsAA (https://toolsaa.com)
# ==============================================================================
set -euo pipefail

echo "=========================================================="
echo " [ToolsAA] Deploying Systemd Timer: db-backup"
echo "=========================================================="

if [ "$EUID" -ne 0 ]; then
  echo "[-] Error: Root privileges required. Re-run with: sudo bash $0" >&2
  exit 1
fi

TARGET_DIR="/etc/systemd/system"

# 1. Write companion service unit
echo "[+] Installing ${TARGET_DIR}/db-backup.service..."
cat << 'EOF' > "${TARGET_DIR}/db-backup.service"
[Unit]
Description=Daily Off-Peak Database Dump and Sync
Documentation=man:systemd.service(5)
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh --all --compress --dest /var/backups
WorkingDirectory=/var/backups
User=postgres
Group=postgres
TimeoutStartSec=1h
Nice=10

# Hardening & Sandboxing
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=true
StandardOutput=journal
StandardError=journal
SyslogIdentifier=db-backup
EOF

# 2. Write timer unit
echo "[+] Installing ${TARGET_DIR}/db-backup.timer..."
cat << 'EOF' > "${TARGET_DIR}/db-backup.timer"
[Unit]
Description=Timer for Daily Off-Peak Database Dump and Sync
Documentation=man:systemd.timer(5)

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=15m
AccuracySec=1m
Unit=db-backup.service

[Install]
WantedBy=timers.target
EOF

# 3. Apply secure unit file permissions (644)
chmod 644 "${TARGET_DIR}/db-backup.service" "${TARGET_DIR}/db-backup.timer"

# 4. Reload systemd daemon
echo "[+] Reloading systemd manager configuration..."
systemctl daemon-reload

# 5. Enable and immediately activate the timer
echo "[+] Enabling and starting db-backup.timer..."
systemctl enable --now "db-backup.timer"

# 6. Verify timer status and list upcoming triggers
echo ""
echo "=========================================================="
echo " [✓] Deployment Complete! Next Scheduled Executions:"
echo "=========================================================="
systemctl list-timers --all | grep -E "db-backup|NEXT" || true
echo ""
echo "To test service execution immediately:"
echo "  sudo systemctl start db-backup.service"
echo "To view execution logs:"
echo "  journalctl -u db-backup.service -f"
Timer Trigger Mode
calendar Trigger

*-*-* 02:30:00

Execution Unit Type
Type=oneshot

User: postgres • Nice (Priority): 10

Sandbox & Jitter
Full Sandbox

Persistent (Catch-up missed executions on boot): Yes • Jitter: 15m

Zero-Knowledge Local Execution

All data processing, parsing, and compilation execute strictly inside your local browser memory. Zero external server uploads.

Sub-Millisecond AST Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technical Reference & Architecture Guide

Linux Systemd (.timer & .service) Unit Generator — Reference Guide

Build systemd timer and companion service unit files with OnCalendar scheduling, OnBootSec intervals, Persistent execution, and random delays.

Key Parameters & Controls

unitNamestring

Base name for the timer and companion service unit files (generates <unitName>.timer and <unitName>.service).

Default: backup-job
onCalendarstring

Realtime calendar event specification formatted according to systemd.time(7) syntax for scheduled execution.

Default: *-*-* 03:00:00
onBootSecstring

Monotonic delay elapsed after system boot before the timer triggers its associated service.

Default: 15min
persistentboolean

Stores the last trigger timestamp on disk so missed executions run immediately when the machine resumes from shutdown.

Default: true
randomizedDelaySecstring

Jitter window applied to the schedule to prevent resource spikes and thundering herd contention across fleets.

Default: 10m
execStartstring

Absolute binary path and arguments executed by the companion systemd service unit.

Default: /usr/local/bin/backup.sh

Pro Tips & Best Practices

Run systemd-analyze calendar

Run systemd-analyze calendar '<expression>' in your terminal to view normalized timestamps and upcoming scheduled iterations before deployment.

Keep Timer and Service Names Identical

When <name>.timer and <name>.service share identical file prefixes, systemd binds them automatically without requiring an explicit Unit= directive.

Configure Type=oneshot

Configure Type=oneshot with RemainAfterExit=no in companion service units to ensure ephemeral tasks exit cleanly between timer intervals.

Run systemctl list-timers --all

Run systemctl list-timers --all to inspect scheduled execution times, remaining countdowns, and last trigger statuses across all system units.

Common Gotchas & Troubleshooting

Timer unit is active but the companion service never fires

Execute sudo systemctl daemon-reload after modifying unit files. Ensure ExecStart specifies an absolute path and verify journalctl -u <name>.service -e for execution errors.

Scheduled tasks failed to execute after rebooting an offline server

Set Persistent=true in the [Timer] section. Systemd records timestamps in /var/lib/systemd/timers/stamp-<name>.timer; without this flag, missed offline triggers are permanently dropped.

Timer triggers continuously in a rapid loop every second

Avoid open-ended second wildcards like *-*-* *:*:*. Specify an exact second such as *-*-* 02:00:00 or step intervals like *:0/15 to prevent continuous execution.

Frequently Asked Questions

Why should I migrate from crontab to systemd timers?▼

Systemd timers provide native journalctl logging, cgroup resource isolation (CPU/memory limits), microsecond precision, dependency ordering (After=network.target), and replace anacron with the Persistent directive.

Where should the generated .timer and .service files be placed?▼

System-wide units should be placed in /etc/systemd/system/. For rootless user-level tasks, save unit files in ~/.config/systemd/user/ and manage them with systemctl --user.

How do I activate and start the newly generated timer?▼

Run sudo systemctl daemon-reload to register the new units, then enable and start the timer using sudo systemctl enable --now <name>.timer.

Can a single timer unit trigger multiple service units?▼

A timer unit targets one service unit by default. To trigger multiple services, target a .target unit or invoke a coordinating script that runs the individual tasks.

Related Tools & Utilities

All Tools →