Maîtrisez le cycle de vie des services Linux

Plusieurs collaborateurs signalent qu'ils n'arrivent plus à accéder à l'application web interne de l'entreprise. Alex, notre architecte système, se tourne vers vous :

Le serveur tourne parfaitement et l'accès à distance que nous avons sécurisé ensemble fonctionne très bien. Le problème vient d'ailleurs : c'est le service de l'application elle-même qui s'est arrêté.

C'est précisément dans ce genre de situation concrète que vous allez devoir intervenir au quotidien. Avant de déployer de nouveaux outils, vous devez comprendre comment le système gère ces processus en arrière-plan, et surtout, savoir comment diagnostiquer un composant qui refuse de démarrer.

Comprenez ce qu’est un service Linux

Dès vos premières investigations, vous remarquerez qu'une multitude de programmes s'exécutent sur le serveur sans que personne ne les ait lancés manuellement. 

Contrairement aux applications bureautiques classiques que vous ouvrez et fermez vous-même, les services démarrent, s’arrêtent et redémarrent indépendamment des utilisateurs connectés. Ils sont indispensables au bon fonctionnement d’un serveur, car ils assurent en continu les fonctions attendues par les utilisateurs et les autres machines. Sur la plupart des distributions Linux modernes, la gestion des services est centralisée par systemd. Avec systemd, les services sont décrits par des unités de type .service. Ces unités permettent au système de savoir comment démarrer un service, comment l’arrêter, comment vérifier son état et, dans certains cas, comment le relancer automatiquement. Prenons deux exemples concrets que vous manipulerez régulièrement :

• SSH, souvent nommésshousshdselon les distributions, permet de se connecter à distance de manière sécurisée à une machine Linux. Si ce service s’arrête, vous risquez de perdre l’accès distant au serveur.

• Apache, appelé généralementapache2sur Debian, est un serveur web. Son rôle est d’héberger et de diffuser des pages ou applications web aux utilisateurs.

Une application exploitable repose toujours sur un service maîtrisé. Si le service sous-jacent est instable ou mal configuré, c'est l'application entière qui devient indisponible pour le reste de l'entreprise.

Gérez les services avec systemctl

Maintenant que vous savez que systemd est le chef d'orchestre qui gère tout en arrière-plan, comment interagir avec lui ? C'est là qu'intervient la commande systemctl. 

Avant d’agir sur un service, il faut distinguer deux informations :

1. L’état actuel du service indique ce qui se passe maintenant. Le service est-il en cours d’exécution ? Est-il arrêté ? A-t-il rencontré une erreur ? Vous pouvez le vérifier avec :  systemctl status apache2

1. L’activation au démarrage indique ce qui se passera au prochain démarrage de la machine. Le service se lancera-t-il automatiquement, ou faudra-t-il le démarrer manuellement ? Vous pouvez le vérifier avec :

systemctl is-enabled apache2

Pour agir sur un service, vous utiliserez généralement  sudo  :

sudo systemctl stop apache2

sudo systemctl start apache2

sudo systemctl restart apache2

Vous pouvez également définir son démarrage automatique :

sudo systemctl enable apache2

sudo systemctl disable apache2

Dans notre cas, l’application web interne repose sur un serveur Apache (apache2). Si ce service s’arrête, l’application devient immédiatement inaccessible. Votre premier réflexe sera donc de vérifier son état avec  systemctl status  .

Découvrez maintenant comment observer l’état d’un service, modifier son état d’exécution et configurer son démarrage automatique en toute sécurité.

 Dans cette vidéo, on a :

• vérifié l’état actuel d’un service avecsystemctl status,

• distingué l’état actuel du service de son activation au démarrage,

• arrêté puis relancé un service avecstopetstart,

• configuré son démarrage automatique avecenable,

• vérifié cette configuration avecsystemctl is-enabled.

Analysez les logs pour diagnostiquer un service

Vous avez vérifié l’état du service avecsystemctl statuset constaté qu’il est en échec (  failed  ). Vous avez tenté de le relancer mais le service retombe immédiatement en erreur.

À ce stade, vous savez ce qui se passe : le service ne démarre pas. La prochaine étape consiste à comprendre pourquoi.

Avecsystemd, l’outil principal pour consulter ces journaux estjournalctl. Il permet d’explorer les événements enregistrés par le système et de les filtrer pour retrouver ceux qui concernent un service précis.

C’est indispensable, car un serveur produit en permanence de nombreux événements. Sans filtre, les logs deviennent rapidement difficiles à exploiter. Votre objectif n’est donc pas de tout lire, mais de retrouver les lignes utiles au bon moment.

Alex le résume souvent ainsi :

Un service qui échoue laisse généralement une trace. Ton rôle n’est pas de deviner la panne, mais de retrouver cette trace, de l’interpréter, puis seulement ensuite d’agir.

Découvrez maintenant comment passer d’un service en échec à une cause probable, en filtrant les bons logs et en lisant les bons indices.

Dans cette vidéo, on a :

• consulté les journaux centralisés avecjournalctl,

• filtré les logs pour se concentrer sur un service précis grâce à l'option-u,

• utiliséjournalctl -xepour consulter rapidement les derniers événements détaillés,

• identifié une cause probable avant toute modification de configuration.

À vous de jouer

Contexte 

L'incident de ce matin avec l'application web est résolu, mais Alex souhaite s’assurer que vous avez les bons réflexes avant de déployer de nouveaux services.

Cette fois, vous allez vous concentrer sur un service essentiel : l’accès distant au serveur. C’est grâce à lui que vous pouvez administrer la machine sans être directement devant sa console. Votre objectif est double : vérifier que ce service est bien opérationnel, et savoir retrouver ses messages récents dans les logs en cas d’alerte.

Toutes vos manipulations doivent être réalisées en toute sécurité sur votre machine virtuelle Debian.

Consignes

Pour valider cette étape technique, vous allez devoir interroger la machine et piloter son service d'accès distant :

1. Identifiez le service qui gère la connexion SSH sur votre serveur. Sur Debian, il s’appelle généralementssh.

2. Vérifiez son état actuel avecsystemctl status ssh. Le service doit être actif.

3. Vérifiez s’il est configuré pour démarrer automatiquement avecsystemctl is-enabled ssh.

4. Redémarrez manuellement le service avecsudo systemctl restart ssh, afin de simuler l’application d’une nouvelle configuration.

5. Consultez les logs liés à ce service avecsudo journalctl -u ssh.

6. Repérez les messages récents qui confirment que le service a bien été redémarré. Vous pouvez vous aider desudo journalctl -xepour consulter les derniers événements détaillés.

En résumé

• Un service Linux est un programme exécuté en arrière-plan pour fournir une fonctionnalité continue, comme l’accès distant ou l’hébergement web, indépendamment des utilisateurs connectés.

• Sur les distributions modernes, les services sont gérés parsystemd, qui s’appuie sur des unités de type.servicepour définir leur démarrage, leur arrêt et leur supervision.

• La commandesystemctlpermet de vérifier l’état actuel d’un service, de le démarrer, l’arrêter ou le redémarrer, ainsi que de configurer son lancement automatique au démarrage du système.

• L’état d’exécution d’un service et son activation au démarrage sont deux informations distinctes qu’il faut systématiquement différencier lors d’un diagnostic.

• L’analyse des journaux avecjournalctl, notamment via les options-uet-xe, permet d’identifier précisément la cause d’un service en échec avant toute modification de configuration.

Vous savez maintenant contrôler un service Linux, vérifier son état et consulter ses logs en cas de problème.

Il est temps de mettre ces réflexes en pratique avec un service concret : un serveur SFTP, qui permettra aux équipes de transférer des fichiers de manière sécurisée.