EQVPS

Comment créer un service systemd pour garder une app en marche

Transformez n'importe quel script ou app en service géré qui démarre au boot, redémarre s'il plante et journalise vers journalctl. Écrivez un fichier unit, activez-le et vérifiez son état — la façon standard de faire tourner quelque chose 24/7 sous Linux.

Lancer une app avec & ou nohup va bien jusqu'à ce que le serveur redémarre, que le processus plante ou que vous vouliez trouver ses journaux — là, tout s'effondre. systemd est la réponse standard : il démarre votre app au boot, la redémarre si elle meurt et capture ses journaux. Transformer un script ou un binaire en service géré tient en un petit fichier.

1. Écrivez un fichier unit

Créez /etc/systemd/system/myapp.service :

[Unit]
Description=My application
After=network.target

[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/run.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Ajustez ExecStart, WorkingDirectory et User à votre app. Restart=always est ce qui la garde en vie.

2. Créez un utilisateur dédié (recommandé)

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /opt/myapp

Tourner en utilisateur non-root limite les dégâts si l'app est un jour compromise.

3. Activez-le et démarrez-le

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

enable le fait démarrer au boot ; --now le démarre immédiatement.

4. Vérifiez l'état et les journaux

sudo systemctl status myapp
journalctl -u myapp -f       # suivre les journaux en direct

Commandes du quotidien

sudo systemctl restart myapp   # redémarrer après un changement
sudo systemctl stop myapp      # l'arrêter
sudo systemctl disable myapp   # ne plus démarrer au boot

Mises en garde honnêtes

Étapes suivantes

Un service systemd, c'est ainsi que vous gardez n'importe quoi en marche 24/7 — par exemple un agent IA qui tourne en continu ou le relais derrière un serveur RustDesk auto-hébergé. Si votre app est plutôt conteneurisée, le --restart unless-stopped de Docker joue le même rôle — voir comment installer Docker.

FAQ

Pourquoi systemd plutôt que simplement lancer l'app en arrière-plan ?

Un processus en arrière-plan (avec & ou nohup) meurt au redémarrage, ne revient pas s'il plante et éparpille ses journaux. Un service systemd démarre automatiquement au boot, redémarre en cas d'échec et envoie sa sortie vers journalctl. C'est la façon standard et fiable de faire tourner quelque chose de durable sous Linux.

Où vont les fichiers unit ?

Vos propres services vont dans /etc/systemd/system/, un fichier par service, nommé quelquechose.service. Après en avoir créé ou modifié un, lancez 'systemctl daemon-reload' pour que systemd prenne le changement, puis activez-le et démarrez-le.

Que fait 'Restart=always', et y a-t-il des inconvénients ?

Il dit à systemd de redémarrer le service chaque fois qu'il se termine, pour n'importe quelle raison — la clé pour garder quelque chose en marche. Le seul piège est la boucle de plantage : si l'app échoue instantanément au démarrage, systemd la redémarre sans cesse. Ajoutez 'RestartSec=5' pour espacer les tentatives, et consultez les journaux pour corriger l'erreur de fond.

Comment voir les journaux du service ?

Utilisez 'journalctl -u yourservice -f' pour suivre la sortie en direct, ou sans -f pour lire l'historique. systemd capture stdout et stderr automatiquement, donc vous n'avez pas à câbler de fichiers de journaux vous-même.

Le service doit-il tourner en root ?

De préférence non. Créez un utilisateur dédié non-root et définissez 'User=' dans l'unit, pour qu'une compromission de l'app ne livre pas toute la machine. Ne tournez en root que si le service en a réellement besoin.

Commentaires

Pas encore de commentaires. Soyez le premier.

Laisser un commentaire

Les commentaires sont modérés avant leur publication.