🔷Arrêt bloqué sur un portable Linux (Latitude e6230)

🔷Arrêt bloqué sur un portable Linux (Latitude e6230)

Notes

Contexte

  • Portable Dell Latitude E6230
  • CachyOS, KDE Plasma (Wayland)
  • Disque chiffré LUKS2
  • Mullvad VPN et Tailscale actifs en permanence
  • Partage NFS /sharenfs monté depuis un serveur du tailnet (100.64.0.2), via x-systemd.automount

Symptôme : de temps en temps, l’arrêt ne se termine pas et je dois forcer l’extinction. Le problème n’est pas systématique.

Première piste : LUKS

Le journal du boot précédent se lit avec :

1

journalctl -b -1 -e --no-pager | tail -n 80

Il contient ces lignes :

1
2

systemd-cryptsetup[...]: Device luks-... is still in use.
systemd-cryptsetup[...]: Failed to deactivate 'luks-...': Device or resource busy

C’est trompeur. À ce stade, la racine est encore montée, donc le volume chiffré est forcément « en cours d’utilisation ». Ce message est normal à chaque arrêt et n’explique rien.

La vraie cause : l’ordre d’arrêt

En filtrant le journal sur les services concernés :

1

journalctl -b -1 --no-pager -o short-precise | grep -iE "tailscale|mullvad|sharenfs|nfs:" | tail -n 40

on obtient la chronologie suivante :

1
2
3
4
5
6
7

19:02:23  Mullvad VPN daemon arrêté
19:02:23  interface tailscale0 passée en unmanaged
19:02:24  tailscaled.service arrêté
19:02:28  sharenfs.automount désactivé  (le montage NFS reste actif)
19:05:29  kernel: nfs: server 100.64.0.2 not responding, timed out
19:08:30  kernel: nfs: server 100.64.0.2 not responding, timed out
19:08:30  boot.mount / tmp.mount : Unmounting timed out

Mullvad et Tailscale s’arrêtent avant le démontage du NFS.
Le serveur devient injoignable alors que le montage est encore actif, et le noyau attend pendant six minutes (montage « hard » par défaut).
Le problème n’est pas systématique parce qu’il n’apparaît que si /sharenfs a été consulté pendant la session.

Piège de lecture : l’arrêt de sharenfs.automount ne signifie pas que le partage est démonté. Seule l’unité sharenfs.mount compte.

Unité Origine Rôle
sharenfs.automount générée depuis fstab surveille /sharenfs et déclenche le montage au premier accès
sharenfs.mount générée depuis fstab le montage NFS lui-même
sharenfs-umount.service écrite à la main démontage forcé à l’arrêt

Correction

1. Ligne fstab

Ajouter les dépendances sur tailscaled et mullvad-daemon, raccourcir le délai d’inactivité, et éviter l’attente infinie :

1

100.64.0.2:/sharenfs /sharenfs nfs4 nofail,_netdev,x-systemd.automount,x-systemd.requires=tailscaled.service,x-systemd.requires=mullvad-daemon.service,x-systemd.requires=tailscale-ready.service,x-systemd.requires=tailscale-mullvad.service,x-systemd.mount-timeout=30s,x-systemd.idle-timeout=60,nfsvers=4.2,soft,timeo=50,retrans=2 0 0
  • x-systemd.requires= impose aussi l’ordre inverse à l’arrêt : le montage est démonté avant ces services.
  • x-systemd.idle-timeout=60 : le partage est démonté après une minute d’inactivité, donc rarement monté à l’extinction.
  • soft,timeo=50,retrans=2 : abandon au lieu d’une attente infinie. soft peut faire perdre des écritures si le serveur disparaît en plein transfert. À réserver à un partage surtout utilisé en lecture.

2. Un filet de sécurité : sharenfs-umount.service

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[Unit]
Description=Demonter /sharenfs avant l'arret de Tailscale et Mullvad
After=network-online.target tailscaled.service mullvad-daemon.service tailscale-mullvad.service
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=-/usr/bin/umount -l -f /sharenfs
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

systemd arrête les services dans l’ordre inverse du démarrage.
Ce service démarre après le réseau, donc il s’arrête avant : son ExecStop démonte /sharenfs pendant que le tunnel existe encore.
Le - devant la commande ignore l’erreur si le partage n’est pas monté.

Activation :

1
2
3

sudo systemctl daemon-reload
sudo systemctl enable --now sharenfs-umount.service
systemctl status sharenfs-umount.service   # active (exited) est normal

Après une modification de fstab :

1
2
3

sudo umount -l /sharenfs 2>/dev/null
sudo systemctl daemon-reload
sudo systemctl restart sharenfs.automount

Vérification

Après un arrêt normal, avec /sharenfs consulté pendant la session :

1

journalctl -b -1 --no-pager -o short-precise | grep -iE "sharenfs|mullvad-daemon.service|tailscaled.service|nfs:" | tail -n 20

Résultat attendu : sharenfs.mount démonté avant Stopped Mullvad VPN daemon et Stopped Tailscale node agent, et plus aucun message not responding. (À confirmer après le prochain arrêt.)

Outil de diagnostic utile

Pour garder une trace de l’état du système à la toute fin d’un arrêt, quand journald est déjà coupé :

1
2
3
4
5
6
7
8
9
10

sudo tee /etc/systemd/system-shutdown/debug.sh >/dev/null <<'EOF'
#!/bin/sh
D=/var/log/shutdown-debug
mount -o remount,rw / 2>/dev/null
mkdir -p "$D"
{ date; cat /proc/mounts; cat /proc/swaps; dmsetup ls --tree; ls /sys/block/dm-*/holders; } > "$D/$(date +%F_%H%M%S).txt" 2>&1
ls -1t "$D" | tail -n +11 | while read f; do rm -f "$D/$f"; done
sync
EOF
sudo chmod +x /etc/systemd/system-shutdown/debug.sh

Il conserve un fichier par arrêt (les dix derniers). Ici, il n’a finalement pas été nécessaire, mais il aurait servi si le blocage avait eu lieu après l’arrêt des services.

À retenir

  • Un message still in use de systemd-cryptsetup à l’arrêt est normal et ne désigne pas la cause du blocage.
  • Un montage réseau doit dépendre des services qui assurent la connexion (tailscaled, VPN) pour être démonté avant eux.
  • Les blocages intermittents à l’arrêt viennent souvent d’un état qui n’existe que dans certaines sessions : ici, avoir consulté un partage.
  • Lire le journal du boot précédent (journalctl -b -1) avant de formuler une hypothèse évite de chercher au mauvais endroit.