Accueil
Générateur Systemd Timer
systemd v240+ Standard•OnCalendar, OnBootSec, Persistent & gigue (Jitter)

Linux Systemd (.timer & .service) Unit Generator

Créez et structurez des unités de minuterie systemd et des services associés prêts pour la production avec planification OnCalendar, intervalles OnBootSec, exécution Persistent et délais aléatoires.

Préréglages :
PlanificationCalendar 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
Entrée
Nom et identification de l unité/etc/systemd/system/
.timer
Mécanisme de déclenchement
Exécution du service associéType=oneshot
Bac à sable et durcissement de la sécuritéEspaces de noms Linux
#!/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"
Mécanisme de déclenchement
calendar Déclencheur

*-*-* 02:30:00

Commande d'exécution
Type=oneshot

User: postgres • Nice (Priority): 10

Sandbox & Jitter
Bac à sable complet

Persistant: Oui • Jitter: 15m

Exécution Locale Zero-Knowledge

Tous les traitements, analyses et générations s'exécutent strictement dans la mémoire de votre navigateur. Zéro transmission vers un serveur externe.

Moteur Réactif Submilliseconde

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

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Référence technique et guide d'architecture

Guide Développeur du Générateur d'Unités Systemd (.timer et .service) sous Linux — Guide de référence

Créez et structurez des unités de minuterie systemd et des services associés prêts pour la production avec planification OnCalendar, intervalles OnBootSec, exécution Persistent et délais aléatoires.

Paramètres clés et contrôles

unitNamestring

Nom de base partagé pour la paire timer et service (génère <unitName>.timer et <unitName>.service).

Par défaut : backup-job
onCalendarstring

Spécification de calendrier en temps réel selon la syntaxe systemd.time(7) pour les exécutions périodiques.

Par défaut : *-*-* 03:00:00
onBootSecstring

Délai monotonique après le démarrage du système avant le tout premier déclenchement du timer.

Par défaut : 15min
persistentboolean

Si true, enregistre l'horodatage sur disque pour exécuter immédiatement les tâches manquées lors du redémarrage si le système était hors tension.

Par défaut : true
randomizedDelaySecstring

Fenêtre de temporisation aléatoire (gigue/jitter) évitant les surcharges simultanées sur des grappes de serveurs.

Par défaut : 10m
execStartstring

Chemin absolu et arguments de la commande exécutée par le service compagnon.

Par défaut : /usr/local/bin/backup.sh

Conseils de pro et bonnes practices

Exécutez systemd-analyze calendar

Exécutez systemd-analyze calendar '<expression>' dans votre terminal pour inspecter les horodatages normalisés, visualiser les prochaines occurrences planifiées et repérer les erreurs de syntaxe avant le déploiement.

Lorsque <name>.timer et <name>.service

Lorsque <name>.timer et <name>.service portent le même nom, systemd associe automatiquement l'unité de service sans nécessiter de directive explicite Unit= dans la section [Timer].

Définissez Type=oneshot avec

Définissez Type=oneshot avec RemainAfterExit=no dans l'unité de service pour que le processus se termine proprement une fois le travail accompli, prévenant ainsi les conflits d'état lors des déclenchements futurs.

Vérifiez l'ensemble des minuteries du

Vérifiez l'ensemble des minuteries du système, le compte à rebours avant la prochaine exécution et l'état de la dernière itération en exécutant systemctl list-timers --all.

Pièges courants et dépannage

Le timer est actif mais le service associé ne s'exécute jamais

Exécutez systématiquement sudo systemctl daemon-reload après modification ou ajout de fichiers dans /etc/systemd/system/. Vérifiez que ExecStart pointe vers un chemin absolu valide et consultez les journaux avec journalctl -u <name>.service -e.

Les tâches de maintenance ont été ignorées après le redémarrage d'une machine éteinte

Activez Persistent=true dans la section [Timer]. Systemd enregistre l'état dans /var/lib/systemd/timers/stamp-<name>.timer ; sans cette option, les déclenchements passés durant l'arrêt sont définitivement perdus.

Le timer se déclenche en boucle continue chaque seconde

Évitez les caractères génériques ouverts sur les secondes comme *-*-* *:*:*. Indiquez une seconde fixe telle que *-*-* 02:00:00 ou un pas d'intervalle comme *:0/15 pour que la commande ne s'exécute qu'une fois par minute prévue.

Foire aux questions (FAQ)

Pourquoi privilégier les timers systemd par rapport à crontab ?▼

Les timers systemd offrent une intégration native avec journalctl pour un logging unifié, le contrôle des ressources (CPU, mémoire) via cgroups, une précision à la microseconde, la gestion des dépendances réseau et remplacent anacron grâce à la directive Persistent.

Où installer les fichiers .timer et .service générés ?▼

Pour des services globaux au niveau du système d'exploitation, placez-les dans /etc/systemd/system/. Pour des tâches utilisateur sans privilèges root, déposez-les dans ~/.config/systemd/user/ et pilotez-les avec systemctl --user.

Comment activer et démarrer la nouvelle unité de timer ?▼

Lancez sudo systemctl daemon-reload, puis activez et démarrez le timer via sudo systemctl enable --now <name>.timer. Contrôlez son statut à l'aide de systemctl status <name>.timer.

Un seul timer peut-il déclencher plusieurs services ?▼

Par défaut, un timer cible un seul service associé. Pour déclencher plusieurs services distincts, pointez vers une unité de type .target ou utilisez un script shell coordinateur qui invoquera successivement chaque commande.

Outils et utilitaires connexes

Tous les outils →
Guide Développeur du Générateur de Configuration TypeScript (tsconfig.json)Développement

Générez des configurations tsconfig.json modernes et robustes pour Next.js, Node.js, Vite ou bibliothèques avec mode strict, alias de chemins et résolution de modules.

Ouvrir l'outil→
Guide Développeur : Générateur de DDL CREATE TABLE JSON vers ClickHouseDéveloppement

Convertissez des documents JSON en DDL SQL ClickHouse avec moteur MergeTree, types UInt/Int/Float/String/DateTime et mappage de colonnes Array/Nested.

Ouvrir l'outil→
Guide Développeur : Générateur de Schéma de Table Google BigQuery depuis JSONDéveloppement

Déduisez et convertissez des objets JSON en schémas de table Google Cloud BigQuery au format JSON avec prise en charge des types RECORD, STRING, INTEGER, NUMERIC et TIMESTAMP.

Ouvrir l'outil→
Guide Développeur : Générateur de DDL CREATE TABLE JSON vers SnowflakeDéveloppement

Convertissez vos structures et charges utiles JSON en instructions SQL CREATE TABLE prêtes pour la production dans Snowflake avec des types de données optimisés tels que VARIANT, VARCHAR, NUMBER, BOOLEAN et TIMESTAMP_NTZ.

Ouvrir l'outil→
Guide Développeur : Générateur de Variables et Locals Terraform HCL depuis JSON / YAMLDéveloppement

Convertissez des structures JSON et YAML en contraintes de types HCL Terraform (type = object({...})), valeurs par défaut, blocs locals et fichiers terraform.tfvars.

Ouvrir l'outil→
Guide Développeur : Convertisseur OpenAPI / Swagger vers GraphQL SDLDéveloppement

Convertissez les points de terminaison REST, corps de requête et schémas JSON OpenAPI 3.0/3.1 et Swagger 2.0 en types, requêtes, mutations et entrées GraphQL SDL.

Ouvrir l'outil→