Générateur de fichier service systemd
Transforme une commande en vrai service systemd : remplis ExecStart, Type, User et Restart, et copie un fichier unit prêt plus les commandes d installation.
Ce générateur de fichier service systemd transforme une simple commande en vrai service que systemd démarre, arrête et relève après un crash. Remplis les champs que tu connais, la ligne ExecStart, le Type, le User, la politique de redémarrage et les valeurs Environment, et tu repars avec un fichier unit .service complet ainsi que les commandes exactes pour le mettre en place et l activer au démarrage. Tu veux plutôt le job sur un planning, façon cron ? Active le timer et tu récupères aussi un .timer assorti avec une ligne OnCalendar. Charge un preset pour une app Node, un worker Python, un binaire Go ou un backup de nuit. Tout tourne dans ton navigateur, donc rien de ce que tu tapes ne quitte la page.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
générateur de fichier service systemd
T'as une commande. Tu veux qu'elle tourne comme un vrai service, le genre que systemd surveille de près. Remplis ce qu'il faut lancer, qui le lance, comment il doit se relever après un crash. Et hop, tu repars avec un fichier unit .service complet et les commandes exactes pour l'installer. Tu préfères le mettre sur un planning, façon cron ? Active le timer. Tout ça se passe ici même, dans ton navigateur.
À quoi sert un générateur de fichier service systemd
Sur à peu près n'importe quelle machine Linux que tu vas croiser aujourd'hui, c'est systemd qui démarre tes services, les arrête, et les remet debout quand ils tombent. Pour que ton propre programme entre dans la danse, tu écris un fichier unit. Il dit quelle est la commande, qui la lance, quand elle démarre, ce qui se passe quand elle plante. La syntaxe n'est pas énorme. Elle est juste susceptible. Oublie un chemin absolu et le truc échoue sans presque rien dire. Pareil si tu choisis le mauvais Type ou si tu sautes un daemon-reload. Du coup ce générateur prend des champs tout simples et te sort un fichier unit qui marche vraiment, plus les commandes pour le mettre en place.
Trois sections, c'est toute la forme d'un fichier unit. [Unit], ce sont les métadonnées et les histoires d'ordre (Description, After, Wants). [Service], c'est là que le vrai boulot se trouve : la commande dans ExecStart, le Type, le User, la politique de redémarrage. [Install] explique à systemd ce que veut dire concrètement "active ça", presque toujours WantedBy=multi-user.target pour qu'il parte au boot. Cale ces trois-là, et franchement ton programme reste juste là, à côté de nginx et sshd, comme s'il avait toujours été chez lui.
Choisir le bon Type
| Type | À utiliser quand |
|---|---|
simple | Ta commande reste au premier plan, et ce processus est le service. Ce que veulent la plupart des applis. |
exec | Même idée que simple, mais systemd attend que le binaire ait vraiment démarré avant de le déclarer "lancé". Un peu plus strict. Un choix solide sur un systemd récent. |
forking | La commande fait un fork, le parent se termine. C'est la vieille chorégraphie des daemons. En général il te faudra un PIDFile. |
oneshot | Ça tourne, ça se termine, c'est tout. Souvent tu lui colles un timer dessus. Ajoute RemainAfterExit=yes s'il laisse un état derrière lui. |
notify | Le service prévient systemd via sd_notify pour dire qu'il est prêt. Seuls certains trucs parlent ce langage, les serveurs web modernes en font partie. |
Politique de redémarrage et sécurité
Restart=on-failure ramène le service s'il sort avec un code non nul ou s'il crashe. C'est celui que la plupart des trucs devraient utiliser. always va plus loin et redémarre même sur une sortie propre, ce qui colle à un daemon qui n'est jamais censé s'arrêter. Dans les deux cas, règle aussi RestartSec, sinon un service qui plante va juste se cogner en boucle. Côté sécurité : ne le lance pas en root si tu peux l'éviter. Donne-lui un User dédié, pointe-le vers un WorkingDirectory. Et une fois que l'unit de base démarre sans souci, moi j'ajouterais par-dessus les directives de sandboxing, NoNewPrivileges=true et compagnie comme ProtectSystem=strict ou PrivateTmp=true. Peut-être de trop pour un script jetable, mais sur quoi que ce soit de sérieux c'est une assurance pas chère.
Services, timers et cron
Un timer systemd, c'est en gros cron, refait. L'astuce, c'est que tu prends un service oneshot et tu l'associes à une unit .timer qui porte une ligne OnCalendar. Même principe qu'un planning cron, juste plus doux à lire (daily, ou *-*-* 03:00:00). Et les timers savent faire des choses que cron ne sait pas. Tout atterrit dans le journal, donc tu peux vraiment voir ce qui a tourné. Ils rattrapent une exécution que t'as ratée pendant que la machine était éteinte, si tu mets Persistent=true. En plus ils héritent de toute la mécanique de dépendances et de sandboxing que les services ont déjà. Coche la case timer en haut et tu récupères les deux fichiers.
Tout le truc tourne en JavaScript, dans ton navigateur. Rien de ce que tu tapes ne quitte la page, rien n'est loggé nulle part. Bon à savoir, parce que les fichiers unit ont tendance à être pleins de chemins internes et de noms de services que tu préfères garder pour toi.
Sources et pour aller plus loin
Questions fréquentes
Où est-ce que je mets le fichier service ?
Tes propres units vivent dans /etc/systemd/system/yourname.service. T en as fait une, ou tu viens juste de la modifier ? Lance sudo systemctl daemon-reload d abord, pour que systemd relise vraiment ce qui est là. Ensuite sudo systemctl enable --now yourname la démarre et la branche pour le boot d un seul coup.
Pourquoi mon service échoue avec le statut 203/EXEC ?
203/EXEC, c est systemd qui te dit qu il n a pas pu lancer la commande du tout. Neuf fois sur dix c est un chemin dans ExecStart qui n est pas absolu, alors écris-le en entier, /usr/bin/node et ainsi de suite. Ou le fichier n est pas marqué exécutable. Ou le User que t as choisi ne peut tout simplement pas le lancer. Sors systemctl status et journalctl -u yourname et la vraie raison est en général posée juste là.
Quelle est la différence entre enable et start ?
start le lance maintenant, tout de suite, cette seconde. enable concerne le boot : ça pose le lien symbolique WantedBy pour que le truc se lève tout seul la prochaine fois. Les gens confondent ça tout le temps. enable --now fait juste les deux en même temps. Et disable retire le lien de boot mais laisse tranquille ce qui tourne déjà.
Je prends un timer ou cron ?
Si t es déjà sur systemd, moi j irais direct vers un timer. T as les logs du journal, le rattrapage des exécutions ratées, et tout l attirail service comme User et le sandboxing vient gratos avec. Cela dit, cron n est pas mort. Il est parfait pour un petit job récurrent, et il voyage mieux vers des machines qui ne font pas tourner systemd du tout. Le générateur te donne et le service et un timer assorti, comme ça t as pas à choisir à l aveugle.