Qui fait tourner les services sous Linux ?
Ton serveur web doit répondre aux visiteurs, même quand personne n'a ouvert de terminal. Qui le démarre ? Qui le redémarre s'il s'arrête ? Et comment lui dire de démarrer au prochain allumage ? C'est ce problème qui nous mène à systemctl.
Quel problème cherche-t-on à résoudre ?
Imaginons un Raspberry Pi qui héberge un site web. Tu l'allumes : le site doit devenir disponible sans intervention humaine. Tu veux aussi pouvoir arrêter temporairement le serveur pour une maintenance, connaître son état et examiner ses erreurs.
Le besoin fondamental : confier à Linux la gestion du cycle de vie des programmes qui rendent un service en arrière-plan.
Du programme au service
- Un programme est du code sur le disque ; quand on l'exécute, il devient un processus en mémoire.
- Certains processus doivent rester actifs longtemps pour fournir une fonction : serveur SSH, serveur web, base de données… On parle souvent de services.
- Il faut un gestionnaire capable de lancer, arrêter, surveiller et configurer leur démarrage. Sur de nombreuses distributions Linux, c'est systemd.
- L'administrateur a besoin d'un moyen de parler à ce gestionnaire : c'est le rôle de systemctl, un outil en ligne de commande.
systemctl ne contient pas lui-même ton serveur web. Il demande à systemd de gérer une unité, par exemple nginx.service.Qui parle à qui ?
Avance étape par étape dans ce schéma. Les flèches représentent la chaîne de commande, pas le trajet du trafic web.
- 1. Tu veux démarrer un serveur web.
- 2. Tu saisis : sudo systemctl start nginx.
- 3. systemctl transmet la demande à systemd.
- 4. systemd lance l'unité nginx.service et ses dépendances nécessaires.
Nuance : systemd est habituellement le processus d'initialisation (PID 1) sur ces machines. D'autres systèmes d'initialisation existent : systemctl n'est pas universel sur tous les Linux.
Un laboratoire sans risque
Imagine un service nommé demo.service. Clique sur les commandes : la simulation modifie deux propriétés indépendantes. Elle ne touche pas à ton ordinateur.
Commande : aucune
État initial : service arrêté et non activé au démarrage.
- En attente d'une commande.
Modèle volontairement simplifié : on suppose un service valide, sans panne ni dépendances particulières, et des commandes exécutées avec les droits nécessaires. En réalité, un service peut échouer, avoir d'autres états ou être démarré par un déclencheur externe.
Les commandes qui comptent
sudo systemctl start nginxDémarre le service maintenant.
sudo systemctl stop nginxArrête le service maintenant.
sudo systemctl restart nginxRedémarre le service.
sudo systemctl enable nginxConfigure son démarrage automatique, sans nécessairement le lancer maintenant.
sudo systemctl disable nginxRetire cette activation automatique, sans arrêter un service déjà en cours.
sudo systemctl enable --now nginxActive pour les prochains démarrages et démarre immédiatement.
systemctl status nginxAffiche l'état et des informations récentes.
journalctl -u nginxConsulte les journaux associés au service (outil distinct de systemctl).
Attention : sur un serveur distant, arrêter ssh.service ou sshd.service peut interrompre ton accès. Le nom exact des unités dépend de la distribution.
QCM : as-tu compris la logique ?
Choisis une réponse par question, puis consulte les explications.
systemd peut gérer son cycle de vie ; systemctl est le moyen courant de lui donner des ordres. start ≠ enable : « maintenant » et « au démarrage » sont deux questions différentes.Ce que cette idée éclaire
Les notions de processus, service et systemd sont les voisins directs de cet article. Elles figurent aussi dans le graphe 3D de Bash World comme pistes d'exploration.