Les bases de la gestion d’un service sous Linux

Cet article a été publié il y a 7 ans 5 mois 7 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Petit article pour les débutants en administration système sous Linux, et même ceux qui l’utilisent sur leur appareil. Il y a quelques conventions communes à connaître, qui vous permettent notamment de vous y retrouver sur une machine inconnue.

SysVinit vs systemd

Je vais faire taire tout de suite les trolls, le titre du paragraphe est putassier mais au final, je vais juste énoncer les deux systèmes d’initialisation et de gestion des services (au sens start/stop).

SysVinit c’est papy, un héritage de l’époque Unix. Les scripts de démarrage se trouvent dans le dossier /etc/init.d, et les indications de démarrage automatique dans les différents dossiers /etc/rcX.d où X est le niveau d’exécution. Selon la description du Wiki Debian :

Le niveau d’exécution (runlevel) de Linux contrôle le choix des processus ou services qui sont démarrés automatiquement par le système (ou, plus exactement, par Init).

Le système a déjà évolué en douceur, remplaçant des priorités de démarrage séquentielles par une gestion à base de dépendances permettant de mettre à profit la capacité de parallélisation des processeurs modernes, multicoeurs (notamment avec insserv sous Debian).

Et puis est arrivé systemd. Le très décrié logiciel est reparti d’une feuille blanche pour proposer une gestion moderne de l’initialisation des services, et également quelques raffinements qui permettent de laisser derrière nous des années de bricolages divers.

Tout le démarrage des services est à base de dépendances, les scripts se trouvent dans /etc/systemd/system, et toutes les manipulations se font au travers de l’utilitaire systemctl. Et quand je dis toutes, voici un petit exemple de manipulations d’un service en mode avant/après :

Attention, systemd n’est pas parfait, l’absence de retour après le lancement ou l’arrêt d’un service continue de me hérisser le poil, par exemple. Mais il est là pour durer, et même, histoire de ne pas tout foutre en l’air trop vite, il propose le service sysv-compat pour gérer les anciens scripts en douceur. D’ailleurs il est présent pratiquement chez tout le monde : Debian, CentOS, pour ne citer que les plus gros représentants d’OS serveur.

Pour continuer sur les scripts eux-mêmes, l’écriture d’un script pour un service maison est assez simplifiée sur systemd, avec la possibilité de faire un démon d’un script qui n’est pas prévu pour à la base, de manière native, là où il fallait passer par screen ou tmux avant (même si l’utilisation de screen continue d’avoir du sens, par exemple pour les vieux joueurs de Call of Duty pour continuer de disposer d’une console système en plus du RCon). Je ne vais pas les détailler ici, on trouve d’excellentes ressources pour ça, dont les billets sur LinuxFR.

Des fichiers de configuration faciles à trouver

La plupart du temps. Chaque service propose généralement un niveau de paramétrage plus ou moins complet en fonction des services rendus. Dans tous les cas, vous êtes quasiment assuré de trouver le fichier de configuration cherché dans le dossier /etc/<nom_du_service> ou directement dans le fichier /etc/<nom_du_service>.conf. Parfois le fichier se terminera par .ini (coucou PHP) ou .cnf (coucou MySQL), mais l’idée est là. Même les paramètres du noyau que vous voulez modifier sont regroupés dans un fichier de configuration, /etc/sysctl.conf. C’est une des grandes qualités d’un système Linux : tout est fichier, y compris pour les configurations, ce qui permet de ne casser que très peu de chose généralement (sauf si vous cassez celle qui s’occupe de toutes les autres).

Si jamais vous ne trouvez pas le fameux fichier, vous pouvez chercher de différentes manières : moteurs de recherche (Gogol.fr, ou mieux, DuckDuckGo ou Qwant) évidemment, mais directement sur le serveur, c’est mieux. Si vous connaissez le nom du fichier, un coup de locate ou de find. Filtrer les processus lancés est aussi une piste, certains utilisent une option pour indiquer le fichier de configuration (Teamspeak 3 utilise l’option inifile=<chemin_du_fichier>). Analyser le script de démarrage aussi permet de vérifier où peut se trouver le précieux sésame. Plus pointu, mais plus aléatoire, un lsof -p <pid_du_process> peut peut-être vous aider, mais comme il n’est lu qu’au lancement, c’est pas gagné. Dernier recours, un strace au lancement du programme (prendre un peu d’aspirine avant comme j’ai déjà pu le faire pour le debug du FPM).

Un services réseau ? Vérifiez les ports !

En effet, pour ne citer que les plus connus, Serveur Web, SSH, MySQL, tous utilisent du réseau, et donc réservent un port d’écoute à leur lancement. Pour vérifier la liste des ports ouverts, je préfère encore netstat à ss :

ss a l’air vachement lisible comme ça, mais la largeur utilisée fait que la fin de la colonne, sur beaucoup de machines, sera repoussée à la ligne d’après, rendant le constat moins clair.

Voilà, c’est à peu près tout ce qu’il y a à dire je pense, comme d’habitude, si vous pensez que j’ai dit des conneries ou que j’ai oublié d’en dire, n’hésitez pas à me corriger ou me compléter dans les commentaires 😉