Générateur de fichier de service systemd

Gardez un programme Node.js, Python ou Go en fonctionnement sur un serveur Linux, lancez-le au démarrage et relancez-le s’il plante — sans retenir toutes les options de systemd. Renseignez la commande et l’utilisateur, choisissez une politique de redémarrage et des variables d’environnement, puis copiez le fichier .service avec les commandes pour l’installer et le démarrer. Cochez Exécuter selon un calendrier (créer un .timer) pour obtenir un .timer, alternative moderne à cron.

Fonctionne dans votre navigateur — rien de ce que vous saisissez n’est envoyé

Nom du service

Devient le nom du fichier, p. ex. myapp → myapp.service

Description

Commande (ExecStart)

Utilisez le chemin complet du programme, p. ex. /usr/bin/python3 app.py

Répertoire de travail

Exécuter en tant qu’utilisateur

Groupe

Type

La commande reste en cours d’exécution au premier plan (la plupart des applis web et des scripts).

Restart

Attente avant redémarrage (s)

Variables d’environnement

Une CLÉ=valeur par ligne ; les valeurs contenant des espaces sont mises entre guillemets pour vous.

Fichier d’environnement

Nombre max. de fichiers ouverts (LimitNOFILE)

0 conserve la valeur par défaut du système.

Démarrer une fois le réseau en ligneDurcissement de base (pas de nouveaux privilèges, /tmp privé, système en lecture seule)Exécuter selon un calendrier (créer un .timer)

myapp.service

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Installer et démarrer

sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF'
[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service
journalctl -u myapp.service -f

Collez les commandes sur le serveur en tant que root. Après avoir modifié un fichier d’unité, relancez systemctl daemon-reload. Journaux : journalctl -u <name>.

Mode d’emploi

Saisissez le nom du service, la commande avec son chemin complet et le répertoire de travail.
Définissez l’utilisateur, la politique de redémarrage et les variables d’environnement éventuelles.
Ajoutez si vous le souhaitez un durcissement de base ou un calendrier (OnCalendar) pour créer un timer.
Copiez les fichiers générés, ou collez les commandes d’installation dans un shell root sur le serveur.

Explication des options

Type: simple convient aux programmes qui restent au premier plan ; oneshot convient aux scripts exécutés une seule fois, comme les tâches planifiées.
Restart: En cas d’échec relance le service lorsqu’il se termine sur une erreur ou plante ; Toujours le relance aussi après une sortie normale.
OnCalendar: Quand le timer se déclenche, p. ex. daily ou *-*-* 03:00:00 pour 3 h du matin tous les jours. Testez les expressions avec systemd-analyze calendar.

Exemple : une tâche nocturne sous forme de timer

Pour exécuter un script chaque nuit à 3 h, réglez la Commande (ExecStart) sur /usr/local/bin/backup.sh, le nom du service sur backup, Type sur oneshot et Restart sur Jamais, puis cochez « Exécuter selon un calendrier (créer un .timer) » et « Durcissement de base ». Avec l’utilisateur et le répertoire de travail par défaut, le générateur produit deux fichiers. backup.service :

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/srv/myapp
ExecStart=/usr/local/bin/backup.sh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only

et backup.timer :

[Unit]
Description=Run backup on a schedule

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Deux choses changent quand un timer est activé. Le fichier de service perd sa section [Install], car c’est le timer qui le démarre, et les commandes d’installation activent le timer plutôt que le service :

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -f

Le Type n’est pas modifié à votre place quand vous cochez l’option du timer : choisissez donc oneshot vous-même pour les tâches qui se terminent. Un service oneshot combiné à Restart Toujours n’est pas valide, si bien que le générateur omet Restart et affiche un avertissement.

Questions fréquentes

Où placer le fichier ?

Dans /etc/systemd/system/. Exécutez ensuite systemctl daemon-reload puis systemctl enable --now <name>.service — les commandes générées font tout cela.

Pourquoi mon service échoue-t-il avec « Executable path is not absolute » ?

Les anciennes versions de systemd exigent le chemin complet du programme dans ExecStart. Trouvez-le avec which, p. ex. which node.

Timer ou cron ?

Les timers écrivent dans le journal, peuvent rattraper les exécutions manquées pendant que le serveur était éteint et ne s’exécutent jamais deux fois en même temps. cron est plus simple pour une commande d’une ligne et fonctionne toujours très bien.

Confidentialité

Cet outil fonctionne entièrement dans votre navigateur. Vos fichiers et vos textes sont traités sur votre appareil et ne sont jamais envoyés à nos serveurs.