Qu'est-ce qu'une unit systemd et pourquoi utiliser ce générateur ?
Sur Linux moderne (Ubuntu, Debian, Fedora, Arch, Rocky, Alma...) systemd est le programme qui démarre les services au boot, les redémarre quand ils crashent, et lance les jobs planifiés. Un fichier unit est un petit fichier texte dans `/etc/systemd/system/` qui dit à systemd *quoi* lancer et *comment* se comporter.
Ce générateur écrit deux types d'units pour vous :
- Fichiers `.service` ExecStart pour les programmes long-vivants (une web app Node, un worker Python, une base de données).
- Fichiers `.timer` OnCalendar pour les jobs qui doivent tourner sur un planning (le remplacement moderne de cron).
Choisissez un preset, remplissez les champs, copiez le résultat dans un fichier sous `/etc/systemd/system/`, lancez `sudo systemctl daemon-reload && sudo systemctl enable --now myapp.service`, et c'est fini. Tout se passe dans votre navigateur, pas d'upload, pas de compte.
Mode d'emploi
- Choisissez un preset qui ressemble à votre cas (web app Node, worker Python, backup one-shot, base de données, binaire Go, docker compose, serveur statique). Le formulaire se remplit avec des défauts sensés que vous pouvez ajuster.
- Réglez le nom de l'unit (`myapp` devient `myapp.service`), la Description (montrée dans `systemctl status`), et les dépendances (After, Wants, Requires, presque tout le monde veut `network-online.target`).
- Dans la section Service choisissez un Type (utilisez `simple` pour la plupart des apps, `oneshot` pour les scripts qui tournent et sortent, `forking` pour les daemons qui forkent en arrière-plan), les User et Group pour baisser les privilèges, et ExecStart avec le chemin absolu vers votre binaire.
- Choisissez une politique Restart. `on-failure` est le défaut sûr : systemd redémarre seulement si votre programme sort non-zéro ou crashe. `always` est pour les workers long-vivants qui doivent revenir quoi qu'il arrive. Utilisez RestartSec pour régler un back-off (5 secondes c'est bien).
- Ajoutez des variables Environment (NODE_ENV, DATABASE_URL...). Les sensibles (mots de passe, tokens) vont plutôt dans `EnvironmentFile=` : mettez-les dans un fichier `chmod 600` hors de l'unit.
- Hardening optionnel : activez `PrivateTmp`, `ProtectSystem`, `NoNewPrivileges`. Ils ne coûtent rien et limitent les dégâts si le service est compromis. Le générateur explique chacun.
- Basculez vers l'onglet .timer si vous voulez une exécution planifiée au lieu (ou en plus) du service long-vivant. Remplissez OnCalendar (par exemple `daily`, `Mon *-*-* 03:00:00`), activez Persistent pour qu'une exécution ratée s'exécute après un reboot, pointez Unit vers votre service.
- Cliquez sur Copier ou Télécharger. Placez le fichier à `/etc/systemd/system/myapp.service` (et `myapp.timer` si applicable), puis lancez `sudo systemctl daemon-reload`, `sudo systemctl enable --now myapp.service`, et regardez les logs avec `journalctl -u myapp.service -f`.
Quand cet outil est utile
Sept situations concrètes où un bon unit systemd fait gagner du vrai temps :
- Vous avez écrit un programme Node, Python, ou Go et voulez qu'il démarre au boot et redémarre en cas de crash. Mettez un `.service` dans `/etc/systemd/system/` et oubliez `pm2`, `forever`, `screen`, ou `nohup`.
- Vous avez un script qui doit tourner sur un planning (backup nocturne, rapport hebdomadaire, refresh de cache horaire). Une paire `.timer` plus `.service` est le remplacement moderne de cron et les logs vont direct dans journalctl.
- Vous devez faire tourner un programme comme utilisateur non-root avec des permissions contrôlées. `User=` et `Group=` baissent les privilèges ; `ProtectSystem=strict`, `PrivateTmp=yes`, et `NoNewPrivileges=yes` ajoutent du hardening gratuitement.
- Vous gérez une petite flotte et voulez la même définition de service sur les machines. Le fichier unit est du texte simple : versionnez-le en git, déployez avec ansible / un Makefile / scp.
- Vous avez besoin qu'un service attende le réseau ou une base de données avant de démarrer. `After=network-online.target` et `Requires=postgresql.service` rendent l'ordre explicite.
- Une stack docker compose doit démarrer au boot. Un `.service` oneshot avec `ExecStart=docker compose up -d` plus `Requires=docker.service` gère ça proprement.
- Vous voulez des logs centralisés sans rien configurer. `StandardOutput=journal` (le défaut) signifie que `journalctl -u myapp` suit votre programme et `journalctl --since "1 hour ago"` est votre recherche unique.
Questions fréquentes
systemd est le système d'init sur la plupart des distributions Linux modernes (Ubuntu depuis 15.04, Debian depuis 8, RHEL/CentOS/Rocky depuis 7, Fedora depuis 15, Arch, openSUSE...). C'est PID 1, le tout premier process que le kernel démarre, et il est responsable de booter le système, démarrer les services dans le bon ordre, les redémarrer quand ils crashent, lancer les jobs planifiés (timers), gérer les périphériques, monter les systèmes de fichiers, et collecter les logs. Quand vous tapez `sudo systemctl restart nginx`, vous parlez à systemd. Un fichier unit est juste un petit fichier texte au style INI qui dit à systemd comment gérer un tel service, timer, socket ou mount.