Contrôler processus et services Linux avec ps, top et systemctl

À la fin de ce tutoriel, vous saurez lister et filtrer des processus (ps, pgrep, top/htop), les arrêter avec prudence (kill), gérer le job control du shell, piloter des units avec systemctl, lire les logs via journalctl, et créer puis nettoyer un service lab minimal dans /tmp.

Niveau : Débutant · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-10

Slug proposé : linux-processus-systemd · Série : P5 Linux Basics · Remplace / fusionne : N/A — création

Prérequis

• Avoir suivi Installer et mettre à jour des paquets avec apt et dnf (sudo, apt/dnf)
• Une VM ou WSL jetable (Ubuntu/Debian ou Rocky/Alma 9) avec systemd actif (WSL2 avec systemd activé, ou VM classique)
• Terminal bash ; pas de secrets dans les unit files ni dans les scripts lab
• Optionnel : htop installé (sudo apt install -y htop ou sudo dnf install -y htop)

Coût estimé : 0 €. Lab : script + unit fichier dans /tmp et ~/.config/systemd/user/ (ou /etc/systemd/system/ en lab root).

Ce que nous allons construire

Voir les processus (ps, pgrep, top/htop)
  → Signaux kill / kill -9 (prudence)
  → jobs, fg/bg, Ctrl+Z, nohup (bref)
  → Units systemd · systemctl status/start/stop/restart/enable/disable
  → journalctl -u / -f / --since
  → Service lab minimal (script + unit) · timers (aperçu)
  → Vérification + nettoyage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Processus Linux et systemd : ps, top, systemctl, journalctl, unit lab ».)

Cinquième chapitre de Linux Basics. Un processus tourne ; un service systemd le supervise (redémarrage, logs, boot). Analogie cloud : un pod Kubernetes orchestre des processus dans des conteneurs — voir la série Kubernetes et Docker débutant.

Étape 1 — Lister les processus : ps, pgrep, top / htop

Un processus = programme en cours (PID unique). ps photographie ; top / htop rafraîchissent.

# Instantané classique (BSD-like) — lecture seule
ps aux | head -n 15
# Votre shell et ses enfants
ps -ef | grep -E "[b]ash|[s]leep" | head
# Filtrer par nom sans grep bruyant
pgrep -a sshd || pgrep -a bash | head -n 5
# PID d’un binaire précis
pgrep -x sleep || true

Outil	Rôle	Astuce
ps aux	Liste large user/CPU/MEM/CMD	Pipe vers grep / head
ps -ef	Style System V (UID, PPID)	Utile pour voir le parent
pgrep -a nom	PID + ligne de commande	-x = nom exact
top	Vue interactive (q pour quitter)	Touche k = kill (lab)
htop	top amélioré (couleurs, souris)	Paquet optionnel

# top : quittez avec q — ne lancez pas en script non interactif
# top -b -n 1 | head -n 20   # mode batch, une itération
# htop   # si installé ; q pour quitter

Étape 2 — Arrêter un processus : kill et prudence kill -9

kill envoie un signal, pas une « suppression magique ». Par défaut : SIGTERM (15) — demande propre de s’arrêter. SIGKILL (9) force immédiatement (pas de cleanup).

# Lab sûr : processus jetable
sleep 300 &
SPID=$!
echo "PID lab sleep = $SPID"
ps -p "$SPID" -o pid,stat,cmd
# Arrêt propre
kill "$SPID"
sleep 0.5
ps -p "$SPID" >/dev/null 2>&1 && echo "encore vivant" || echo "terminé — OK"

# kill -9 : UNIQUEMENT si TERM ignore (lab / process zombie de test)
# sleep 300 & ; kill -9 $!

Prudence : ne kill -9 pas systemd, sshd, ni un PID inconnu. Vérifiez d’abord avec ps -p PID -o user,cmd. Sur une machine partagée, tuez vos processus lab seulement.

Étape 3 — Job control : jobs, fg/bg, Ctrl+Z, nohup (bref)

Le shell gère des jobs de la session courante (pas systemd).

# Ctrl+Z suspend le processus au premier plan (SIGTSTP)
# Exemple non interactif équivalent :
sleep 120 &
jobs -l
# Remettre en arrière-plan / avant-plan
bg %1 2>/dev/null || true
# fg %1   # reprend au premier plan (Ctrl+C pour interrompre)
# Détacher d’une session qui va se fermer (aperçu) :
# nohup sleep 60 >/tmp/nohup-lab.out 2>&1 &
# Disown / nohup ≠ service systemd : pas de restart au crash ni au boot
kill %1 2>/dev/null || true

Retenez : jobs = session shell ; systemd = supervision machine. Pour un daemon durable, passez aux units.

Étape 4 — systemd et systemctl : units, start/stop/enable

systemd gère des units (.service, .timer, …). L’outil quotidien : systemctl.

Action	Commande	Effet
État	systemctl status nom	Actif ? PID ? dernières lignes log
Démarrer / arrêter	start / stop	Session courante
Relancer	restart	stop + start
Au boot	enable / disable	Lien wants/targets
Activer + démarrer	enable --now	Courant + permanent

# Service système courant (lecture — adaptez le nom si besoin)
systemctl status ssh 2>/dev/null || systemctl status sshd 2>/dev/null || systemctl status cron
# Lister quelques services actifs
systemctl list-units --type=service --state=running | head -n 20
# Ne stoppez PAS ssh/sshd sur une VM distante sans console !
# Exemple lecture seule safe :
systemctl is-enabled cron 2>/dev/null || systemctl is-enabled crond 2>/dev/null || true
systemctl is-active cron 2>/dev/null || systemctl is-active crond 2>/dev/null || true

Ubuntu/Debian : souvent ssh.service, cron.service. Rocky/Alma : sshd.service, crond.service. Même idées systemctl ; noms d’units légèrement différents.

Étape 5 — Logs : journalctl -u, -f, --since

Les services journalisent via le journal systemd.

# Logs d’un unit (ex. ssh ou sshd)
UNIT=$(systemctl list-units --type=service --all 'ssh*' 'sshd*' 2>/dev/null | awk '/loaded/ {print $1; exit}')
echo "Unit observé : ${UNIT:-cron.service}"
journalctl -u "${UNIT:-cron.service}" -n 20 --no-pager
# Suivre en direct (Ctrl+C pour quitter) :
# journalctl -u "${UNIT:-cron.service}" -f
# Depuis une date relative
journalctl -u "${UNIT:-cron.service}" --since "1 hour ago" --no-pager | tail -n 15

-u = unit, -f = follow (comme tail -f), --since / --until = fenêtre temporelle. Sur Rocky comme sur Ubuntu : même journalctl.

Étape 6 — Lab : service minimal (script + unit)

Objectif : un service utilisateur (pas besoin de root pour le cœur du lab) qui exécute un script echo/sleep dans /tmp.

# 1) Script lab
mkdir -p /tmp/lab-systemd "$HOME/.config/systemd/user"
cat > /tmp/lab-systemd/hello-lab.sh << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
echo "[lab] hello-lab démarré à $(date -Is)" >> /tmp/lab-systemd/hello.log
exec sleep 3600
SCRIPT
chmod +x /tmp/lab-systemd/hello-lab.sh

# 2) Unit user
cat > "$HOME/.config/systemd/user/hello-lab.service" << 'UNIT'
[Unit]
Description=Lab hello-lab (Linux Basics tuto 5)
After=default.target

[Service]
Type=simple
ExecStart=/tmp/lab-systemd/hello-lab.sh
Restart=no

[Install]
WantedBy=default.target
UNIT

# 3) Charger, démarrer, vérifier
systemctl --user daemon-reload
systemctl --user start hello-lab.service
systemctl --user status hello-lab.service --no-pager
pgrep -a -f 'hello-lab|sleep 3600' | head
tail -n 3 /tmp/lab-systemd/hello.log

Si Failed to connect to bus (session user sans linger) : loginctl enable-linger "$USER" (lab) ou placez l’unit en system :

# Variante system (VM lab avec sudo) — décommentez si besoin
# sudo cp "$HOME/.config/systemd/user/hello-lab.service" /etc/systemd/system/
# sudo systemctl daemon-reload
# sudo systemctl start hello-lab.service
# sudo systemctl status hello-lab.service --no-pager

enable (boot) : systemctl --user enable hello-lab.service — utile pour comprendre WantedBy ; en lab on disable ensuite.

Étape 7 — Timers systemd (aperçu)

Un .timer déclenche un .service (cron moderne). Exemple d’idée : OnCalendar=hourly + Persistent=true. Syntaxe, systemd-analyze, units drop-in : hors cœur de ce chapitre — bonus dédié systemd avancé (à paraître ; slug linux-systemd-avance). Pour l’instant retenez : timer = calendrier/intervalle, service = charge utile.

Étape 8 — Vérification et nettoyage

# Vérif
systemctl --user is-active hello-lab.service
journalctl --user -u hello-lab.service -n 10 --no-pager 2>/dev/null || true

# Nettoyage lab (disable + stop + rm)
systemctl --user disable --now hello-lab.service 2>/dev/null || systemctl --user stop hello-lab.service
rm -f "$HOME/.config/systemd/user/hello-lab.service"
systemctl --user daemon-reload
rm -rf /tmp/lab-systemd
# Variante system si utilisée :
# sudo systemctl disable --now hello-lab.service
# sudo rm -f /etc/systemd/system/hello-lab.service
# sudo systemctl daemon-reload
pgrep -f hello-lab || echo "lab nettoyé — OK"

Validé si : ps/pgrep OK, kill propre sur sleep, systemctl status/start/stop, journalctl -u, unit lab créée puis disable + rm.

Erreurs fréquentes

Symptôme	Cause	Correction
kill: No such process	PID déjà mort / mauvais PID	Relire ps / pgrep avant
Processus ignore kill	Ignore SIGTERM	Lab : kill -9 en dernier recours ; jamais sur services critiques
Unit not found	Mauvais nom / pas de daemon-reload	Vérifier le chemin .service ; daemon-reload
Failed to connect to bus (user)	Session systemd user absente	linger / se reconnecter / unit system en lab
journalctl vide	Mauvais -u ou pas de logs	systemctl status pour le nom exact ; --since
enable mais pas démarré	enable ≠ start	enable --now ou start séparé

Quiz (3 questions)

1. Différence entre un process et un service systemd ?
– A. Aucune : ce sont des synonymes
– B. Un process est une instance en cours ; un service est une unit qui le démarre, le supervise et peut le relancer
– C. Un service n’a jamais de PID

2. Comment faire démarrer un service au boot ?
– A. systemctl enable nom.service (éventuellement --now pour démarrer tout de suite)
– B. kill -9 1
– C. Uniquement ps aux

3. Où lire les logs d’un unit systemd ?
– A. Uniquement dans /var/log/syslog sans filtre
– B. journalctl -u nom.service (et -f, --since pour affiner)
– C. apt show nom

Réponses : 1‑B · 2‑A · 3‑B

FAQ

Différence service et process ?
Un processus est une exécution concrète (PID). Un service systemd est une unit déclarative : comment démarrer le binaire, sous quel user, s’il redémarre, s’il part au boot. systemctl status montre souvent le PID du process principal.

Comment relancer un service au boot ?
sudo systemctl enable nom.service (system) ou systemctl --user enable nom.service (user). enable crée le lien WantedBy ; start / enable --now agit sur la session courante. disable retire le démarrage automatique.

Où lire les logs d’un unit systemd ?
journalctl -u nom.service ; ajoutez -n 50, -f (suivi), --since "10 min ago". systemctl status nom affiche déjà un extrait récent.

Pour aller plus loin

• man systemctl, man journalctl, man systemd.service, man kill, man ps
• Bonus prévu : systemd avancé (timers, drop-ins, systemd-analyze)
• Prochain tuto : diagnostiquer le réseau avec ip, ss et curl

Maillage série Linux Basics (P5)

← Précédent	Installer et mettre à jour des paquets avec apt et dnf
→ Suivant	Diagnostiquer le réseau Linux avec ip, ss et curl
Hub	Linux Basics
Aussi	Processus orchestrés : Docker débutant · analogie pods (série K8s)

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Processus Linux et systemd : ps, top, systemctl (2026)
• Meta description (≤ 155) : Listez, tuez et supervisez des processus ; démarrez/arrêtez des services systemd et lisez journalctl. Essentiel admin DevOps.
• Focus keyphrase : systemctl
• KW secondaires : systemd, journalctl, ps aux, top htop, kill linux
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-processus-systemd-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Débutant
• Slug : linux-processus-systemd