systemd « Dépendance échouée » : Trouver le service qui bloque le démarrage

janvier 24, 2026 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

Vous redémarrez un nœud Proxmox et il revient avec cette ligne grise satisfaite :
Dépendance échouée pour …. L’interface web est hors ligne, les machines virtuelles sont arrêtées, et vous regardez une console qui dit en substance :
« Quelque chose d’autre n’a pas démarré, donc je n’ai pas démarré non plus. »

Le piège est que l’unité affichée à l’écran est souvent la victime, pas le coupable. systemd rapporte ce qui n’a pas pu démarrer,
pas ce qui a déclenché la réaction en chaîne. Ce guide explique comment trouver le premier domino—rapidement, de manière répétable, et sans deviner.

Le modèle mental : ce que signifie vraiment « Dépendance échouée »

systemd est un moteur de dépendances avec une habitude de journalisation. Il démarre des unités (services, points de montage, périphériques, targets) en fonction des relations déclarées
(Requires=, Wants=, After=, Before=, plus des liens implicites provenant des unités .mount, .device,
et des générateurs).

Un message « Dépendance échouée » pour l’unité X signifie qu’une des dépendances requises de X est passée en état d’échec
(ou n’est jamais apparue dans le délai imparti). Cela peut être :

Un service qui a échoué (code de sortie non nul, timeout, watchdog, configuration manquante).
Un point de montage qui n’a pas monté (fs corrompu, périphérique absent, UUID erroné, ZFS/LVM non importés).
Une unité device qui n’est jamais apparue (disque absent, firmware du HBA en comportement erratique).
Une target qui ne peut pas être atteinte parce que quelque chose requis pour l’atteindre a échoué.

La ligne que vous voyez sur la console est presque toujours en aval. Votre travail est de remonter le flux jusqu’à trouver la première unité qui a échoué, puis
de vous demander : s’agit-il d’une vraie panne (cassé), ou d’un problème d’ordonnancement (dépendances incorrectes) ?

Une citation à garder en tête, attribuée à John Gall (idée paraphrasée) : « Les systèmes complexes qui fonctionnent ont généralement évolué à partir de systèmes plus simples qui fonctionnaient. »
Si votre démarrage est complexe, déboguez-le comme une évolution : trouvez la première erreur, pas le dernier symptôme.

Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Si c’est en production et que vous perdez des minutes, procédez dans cet ordre. L’objectif est d’identifier la première unité en échec et
de savoir si le problème concerne le stockage, le réseau, le cluster, ou simplement une erreur de configuration.

Premier : lister les échecs et inspecter le plus ancien

cr0x@server:~$ systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● pve-cluster.service          loaded failed failed The Proxmox VE cluster filesystem
● zfs-import-cache.service     loaded failed failed Import ZFS pools by cache file

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

Décision : s’il n’y a qu’une ou deux unités en échec, commencez par celle qui semble la plus « fondamentale » (import stockage, montage,
network-online). S’il y en a beaucoup, l’unité « fondamentale » est presque toujours la première en échec.

Deuxième : lire les journaux du démarrage précédent, pas votre session shell actuelle

cr0x@server:~$ journalctl -b -0 -p err..alert --no-pager | head -n 50
Dec 26 09:14:03 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.
Dec 26 09:14:03 server systemd[1]: Failed to start Import ZFS pools by cache file.
Dec 26 09:14:03 server systemd[1]: Dependency failed for ZFS Mount.
Dec 26 09:14:03 server systemd[1]: Dependency failed for Proxmox VE firewall.

Décision : priorisez la première ligne « Failed to start … ». Les entrées « Dependency failed for … » qui suivent sont en aval.

Troisième : tracer la chaîne de dépendance pour l’unité victime

cr0x@server:~$ systemctl list-dependencies --reverse pve-firewall.service
pve-firewall.service
● pve-container.service
● pve-guests.service
● multi-user.target

Décision : si la victime est un service « feuille » (firewall, UI, gestion des guests), arrêtez de lui en vouloir. Remontez vers la dépendance qui
a réellement échoué (import stockage, montage, network-online).

Heuristique pour gagner du temps : stockage avant cluster avant réseau avant « service aléatoire »

Sur les nœuds Proxmox, les blocages au démarrage se regroupent en quatre catégories :
imports de stockage (ZFS/LVM), points de montage (y compris /var/lib/vz),
système de fichiers de cluster (pve-cluster, corosync), et disponibilité réseau.
Les services applicatifs échouent généralement parce que l’un de ces éléments n’a pas démarré.

Blague #1 : systemd est comme un bibliothécaire très strict—si vous murmurez « After=network-online.target » sans vous en occuper correctement, il chuchotera votre démarrage.

Faits intéressants et contexte historique (pour de meilleures intuitions)

systemd a remplacé SysV init sur la plupart des distributions Linux au début des années 2010, apportant un démarrage parallèle et des graphes de dépendances explicites plutôt que l’ordonnancement par scripts shell.
« After= » n’est pas une exigence. Cela ordonne seulement le moment de démarrage. Les gens le confondent encore avec Requires=, et c’est souvent la source des échecs de démarrage.
Les points de montage sont des unités de première classe. systemd génère des unités .mount à partir de /etc/fstab, et elles deviennent des dépendances pour les services qui en ont besoin.
Les unités device apparaissent dynamiquement. Un disque manquant ne « échoue » pas ; il n’apparaît tout simplement jamais. Les unités en aval attendent puis expirent, ce qui ressemble à une panne de service.
ZFS on Linux utilise des services d’import (zfs-import-cache / zfs-import-scan) pour remonter les pools au démarrage ; des fichiers de cache manquants ou des pools renommés peuvent bloquer tout ce qui dépend des montages.
Proxmox s’appuie sur /etc/pve, un système de fichiers de cluster fourni par pmxcfs. Si pmxcfs ne monte pas, une grande partie de la pile de gestion ne peut pas lire la configuration.
« network-online » est source de débats. Différentes distributions fournissent différents services wait-online. Activer le mauvais peut ajouter des délais de démarrage ou créer des impasses quand des bridges/VLAN sont impliqués.
Les changements d’initramfs sont subtils. Un module absent de l’initramfs peut transformer un disque root parfaitement fonctionnel en « introuvable », et le message d’échec de démarrage semblera sans rapport.
systemd peut afficher le chemin critique temporel depuis des années. C’est l’un des moyens les plus rapides pour repérer un goulot d’étranglement au démarrage qui ne « échoue » pas strictement.

Tâches pratiques : commandes, sorties attendues, décisions

Voici des vérifications éprouvées sur le terrain. Chacune inclut une commande, ce que signifie la sortie, et la suite à donner.
Ne lancez pas tout aveuglément ; choisissez les commandes qui correspondent au domaine d’échec que vous observez.

Tâche 1 : Lister les unités en échec (le point de départ évident)

cr0x@server:~$ systemctl --failed --no-pager
  UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
● zfs-mount.service        loaded failed failed Mount ZFS filesystems
● pveproxy.service         loaded failed failed PVE API Proxy Server

2 loaded units listed.

Sens : pveproxy est probablement un dommage collatéral. zfs-mount est fondamental.
Décision : inspecter zfs-mount d’abord, pas le proxy.

Tâche 2 : Inspecter l’unité qui a échoué (status inclut les derniers logs)

cr0x@server:~$ systemctl status zfs-mount.service --no-pager -l
× zfs-mount.service - Mount ZFS filesystems
     Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 09:14:03 UTC; 1min 2s ago
    Process: 812 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE)
   Main PID: 812 (code=exited, status=1/FAILURE)

Dec 26 09:14:03 server zfs[812]: cannot mount 'rpool/data': failed to create mountpoint: /rpool/data
Dec 26 09:14:03 server systemd[1]: zfs-mount.service: Failed with result 'exit-code'.

Sens : l’action en échec est explicite : ZFS ne peut pas créer un point de montage.
Décision : vérifier si le point de montage est en lecture seule, si le montage racine est manquant, ou s’il est bloqué par un conflit fichier/répertoire.

Tâche 3 : Identifier le premier échec dans la timeline de démarrage

cr0x@server:~$ journalctl -b -0 --no-pager | grep -E "Failed to start|Dependency failed" | head -n 30
Dec 26 09:14:02 server systemd[1]: Failed to start Import ZFS pools by cache file.
Dec 26 09:14:03 server systemd[1]: Dependency failed for ZFS Mount.
Dec 26 09:14:03 server systemd[1]: Failed to start Mount ZFS filesystems.
Dec 26 09:14:03 server systemd[1]: Dependency failed for Proxmox VE cluster filesystem.

Sens : zfs-import-cache a échoué en premier. Tout le reste est en cascade.
Décision : inspecter les logs de zfs-import-cache.service ensuite.

Tâche 4 : Plonger dans les journaux d’une unité avec journalctl

cr0x@server:~$ journalctl -u zfs-import-cache.service -b -0 --no-pager -l
Dec 26 09:14:02 server systemd[1]: Starting Import ZFS pools by cache file...
Dec 26 09:14:02 server zpool[771]: cannot open '/etc/zfs/zpool.cache': No such file or directory
Dec 26 09:14:02 server systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:14:02 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.

Sens : pas de fichier de cache. Pas toujours fatal si zfs-import-scan existe, mais votre graphe de dépendances peut forcer l’import par cache.
Décision : confirmer si l’import par scan est activé, ou régénérer le cache depuis une importation fonctionnelle.

Tâche 5 : Vérifier si les pools ZFS sont importables du tout

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool        ONLINE
          mirror-0   ONLINE
            sda3     ONLINE
            sdb3     ONLINE

Sens : le pool existe et est sain, mais n’est pas importé.
Décision : tenter un import manuel (en lecture seule d’abord si vous suspectez des dommages), puis corriger la configuration d’import au démarrage.

Tâche 6 : Import manuel (prudent, mais efficace pour le diagnostic)

cr0x@server:~$ sudo zpool import -N rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Sens : l’import fonctionne. L’échec au démarrage est probablement une question de configuration/ordonnancement (fichier de cache, unité activée), pas de disques morts.
Décision : reconstruire /etc/zfs/zpool.cache et s’assurer que l’unité d’import correcte est activée.

Tâche 7 : Vérifier les bloqueurs wait-online/réseau

cr0x@server:~$ systemd-analyze blame | head -n 15
        1min 32.104s systemd-networkd-wait-online.service
             8.771s pve-cluster.service
             4.210s zfs-mount.service
             2.018s networking.service

Sens : le démarrage n’est pas tant « en échec » que suspendu sur « network online ».
Décision : confirmer si votre nœud a réellement besoin de « online » (souvent non). Si des services Proxmox le requièrent à tort, corrigez les dépendances ou la configuration.

Tâche 8 : Montrer la chaîne critique de démarrage pour une target spécifique

cr0x@server:~$ systemd-analyze critical-chain multi-user.target
multi-user.target @1min 42.909s
└─pve-guests.service @1min 42.870s +37ms
  └─pve-cluster.service @1min 33.982s +8.884s
    └─network-online.target @1min 32.111s
      └─systemd-networkd-wait-online.service @0min 0.008s +1min 32.104s

Sens : la « chaîne critique » montre ce qui a réellement retardé l’atteinte de la target.
Décision : ajuster le service wait-online ou supprimer l’exigence si elle n’est pas nécessaire pour le succès du démarrage.

Tâche 9 : Inspecter les dépendances de l’unité indiquée comme « Dépendance échouée »

cr0x@server:~$ systemctl show -p Requires -p Wants -p After -p Before pve-cluster.service
Requires=system.slice basic.target
Wants=corosync.service
After=network.target syslog.target corosync.service
Before=

Sens : pve-cluster veut corosync et démarre après lui, mais il ne requiert pas explicitement network-online ici.
Votre délai peut venir d’ailleurs, ou une autre unité peut entraîner network-online.
Décision : suivre la chaîne réelle avec systemd-analyze critical-chain et vérifier les drop-ins.

Tâche 10 : Trouver les overrides drop-in (où se cachent les changements « utiles »)

cr0x@server:~$ systemctl cat pve-cluster.service
# /lib/systemd/system/pve-cluster.service
[Unit]
Description=The Proxmox VE cluster filesystem
After=network.target corosync.service
Wants=corosync.service

[Service]
Type=forking
ExecStart=/usr/bin/pmxcfs -l
ExecStop=/usr/bin/killall -TERM pmxcfs
Restart=on-failure

# /etc/systemd/system/pve-cluster.service.d/override.conf
[Unit]
After=network-online.target
Wants=network-online.target

Sens : quelqu’un a ajouté un drop-in faisant attendre pve-cluster sur « online ».
Décision : décider si c’est justifié. Dans la plupart des déploiements Proxmox, ce n’est pas nécessaire ; préférez network.target sauf si vous avez vraiment besoin d’une connectivité routable au démarrage.

Tâche 11 : Confirmer ce que « network-online » est réellement sur votre machine

cr0x@server:~$ systemctl status network-online.target --no-pager -l
● network-online.target - Network is Online
     Loaded: loaded (/lib/systemd/system/network-online.target; static)
     Active: active since Thu 2025-12-26 09:14:00 UTC; 4min ago
       Docs: man:systemd.special(7)

Dec 26 09:14:00 server systemd[1]: Reached target Network is Online.

Sens : la target est satisfaite quand son service « wait » l’est. Quel service wait dépend de votre pile réseau.
Décision : vérifier si vous utilisez systemd-networkd, NetworkManager, ou ifupdown, et désactiver l’unité wait-online inappropriée.

Tâche 12 : Valider les montages liés à Proxmox (fstab et unités mount)

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS /var/lib/vz
/var/lib/vz rpool/data/subvol-100-disk-0 zfs rw,xattr,noacl

Sens : les chemins de stockage Proxmox existent et sont soutenus par le système de fichiers attendu.
Décision : si cela manque ou est incorrect, corriger l’import/mount ZFS/LVM avant de toucher aux services Proxmox.

Tâche 13 : Vérifier fstab pour des bloqueurs de démarrage (UUID erronés, montages obsolètes)

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/fstab
UUID=2f1f9e2d-aaaa-bbbb-cccc-5f9b9d1d2e3f / ext4 defaults 0 1
UUID=deadbeef-1111-2222-3333-444444444444 /mnt/backup ext4 defaults 0 2

Sens : un montage comme /mnt/backup peut bloquer le démarrage si le disque a disparu.
Décision : si ce montage n’est pas critique, ajoutez nofail et un x-systemd.device-timeout= raisonnable. Ou supprimez-le.

Tâche 14 : Confirmer si le périphérique manquant existe

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE FSTYPE UUID                                 MOUNTPOINT
sda   447.1G
├─sda1  512M vfat   8A1B-2C3D                            /boot/efi
├─sda2    1G ext4   0b7c9c2f-1234-5678-90ab-7e1f2c3d4e5f /boot
└─sda3 445.6G zfs_member
sdb   447.1G
└─sdb3 445.6G zfs_member

Sens : si l’UUID du fstab n’apparaît pas ici, le montage échouera.
Décision : corriger l’UUID, vérifier le câblage/HBA, ou marquer le montage nofail s’il est optionnel.

Tâche 15 : Vérifier l’état de pmxcfs et /etc/pve (spécifique à Proxmox)

cr0x@server:~$ mount | grep -E "/etc/pve|pmxcfs"
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Sens : si /etc/pve n’est pas monté, la configuration Proxmox n’est pas disponible ; beaucoup de services échouent « mystérieusement. »
Décision : réparer pve-cluster.service avant de courir après des erreurs pveproxy/pvedaemon.

Tâche 16 : Confirmer l’état de corosync sans deviner

cr0x@server:~$ systemctl status corosync.service --no-pager -l
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:14:01 UTC; 6min ago

Sens : si corosync est down, pve-cluster peut se bloquer ou échouer selon la config.
Décision : inspecter les logs corosync et le réseau (multicast/unicast, interfaces ring), mais ne redémarrez pas tout au hasard.

Tâche 17 : Trouver quelle unité a entraîné une target (qui « voulait »)

cr0x@server:~$ systemctl list-dependencies --reverse network-online.target
network-online.target
● pve-cluster.service
● pvescheduler.service
● zfs-import.target

Sens : ces unités forcent la sémantique « online ».
Décision : revoir si chacune a vraiment besoin de cela ; supprimer les drop-ins qui ajoutent des attentes inutiles.

Tâche 18 : Vérifier la sortie des générateurs (traduction fstab→unité)

cr0x@server:~$ systemctl status mnt-backup.mount --no-pager -l
× mnt-backup.mount - /mnt/backup
     Loaded: loaded (/run/systemd/generator/mnt-backup.mount; generated)
     Active: failed (Result: exit-code) since Thu 2025-12-26 09:14:05 UTC; 2min ago
      Where: /mnt/backup
       What: /dev/disk/by-uuid/deadbeef-1111-2222-3333-444444444444

Dec 26 09:14:05 server mount[901]: mount: /mnt/backup: special device /dev/disk/by-uuid/deadbeef-1111-2222-3333-444444444444 does not exist.

Sens : l’unité mount est générée à partir de fstab et échoue parce que le périphérique est manquant.
Décision : restaurer le chemin/UUID du périphérique, ou rendre le montage optionnel (nofail plus timeout).

Tâche 19 : Vérifier initramfs et la reconnaissance du périphérique root (quand le démarrage est vraiment cassé)

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "zfs|dm_mod|nvme" | head
usr/lib/modules/6.8.12-4-pve/kernel/drivers/md/dm-mod.ko
usr/lib/modules/6.8.12-4-pve/kernel/drivers/nvme/host/nvme.ko
usr/lib/modules/6.8.12-4-pve/updates/dkms/zfs.ko

Sens : les modules critiques apparaissent dans l’initramfs. S’ils n’y sont pas, le noyau ne peut pas trouver les disques tôt.
Décision : reconstruire l’initramfs et vérifier les modules DKMS, surtout après des mises à jour du noyau.

Tâche 20 : Reconstruire l’initramfs (seulement après avoir identifié ce qui manque)

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_12.bin for module i915

Sens : les avertissements sur le firmware GPU sont généralement sans rapport pour des serveurs ; l’absence de firmware pour le stockage/HBA ne l’est pas.
Décision : si vous voyez un firmware manquant pour le stockage/réseau, corrigez cela avant le prochain redémarrage. Sinon, poursuivez.

D’où viennent généralement les échecs de démarrage Proxmox

Quand Proxmox « ne démarre pas », le noyau a probablement démarré correctement. systemd est lancé. L’échec est que le système n’a pas atteint la target qui
inclut vos services de gestion. Proxmox ajoute quelques points de pression particuliers :

1) Import et montages de stockage

Les nœuds Proxmox dépendent presque toujours du stockage local tôt : pools ZFS, groupes de volumes LVM, ou les deux. Si le stockage n’est pas importé,
les unités mount échouent, et ensuite les services qui lisent la configuration ou stockent l’état échouent. La perte de l’UI est un symptôme, pas une cause.

Surveillez :

Échecs d’import ZFS dus à l’absence de /etc/zfs/zpool.cache, pools renommés, ou chemins de périphériques modifiés.
Échecs LVM dus à des PV manquants ou des problèmes d’activation de VG.
Entrées fstab pour des disques de sauvegarde externes qui sont « optionnels » jusqu’à ce qu’ils ne le soient plus.

2) /etc/pve et pmxcfs

/etc/pve n’est pas un répertoire normal. C’est un système de fichiers fuse fourni par pmxcfs, contrôlé par pve-cluster.service.
Si pmxcfs n’est pas monté, beaucoup d’outils Proxmox se comportent comme si la config avait disparu.

La console vous dira sans vergogne « Dépendance échouée pour PVE API Proxy Server. »
C’est exact, mais peu utile. Le proxy dépend de la config et des certificats. Pas de /etc/pve, pas de service.

3) Hypothèses corosync

Dans un cluster, corosync est la façon dont les nœuds s’accordent sur l’appartenance. Un nœud peut aussi fonctionner en mode monopuce, mais la présence d’une configuration de cluster change le comportement au démarrage.
Des interfaces ring mal configurées, un nouveau nom de NIC après un changement matériel, ou une dépendance « network-online » trop stricte peuvent bloquer les unités liées au cluster.

4) target network-online et ordonnancement « utile »

La pile réseau est en couches : le lien monte, les adresses s’appliquent, les routes apparaissent, le DNS peut fonctionner, et seulement alors vous avez « online ».
network.target signifie généralement « le réseau de base est configuré », pas « Internet est accessible ».

Si quelqu’un force les services Proxmox à exiger network-online.target, vous pouvez créer un deadlock où le service wait réseau
attend un bridge/VLAN qui est créé par un service qui attend network-online. Félicitations, vous avez inventé une dépendance circulaire.

Blague #2 : Une boucle de dépendance est la seule fois où votre serveur modélise avec succès les organigrammes d’entreprise.

Traquer l’unité racine : chaînes, ordonnancement, et pourquoi vos yeux vous trompent

L’erreur d’opérateur la plus fréquente dans ces incidents est de traiter le message à l’écran comme la cause racine. systemd affiche « Dépendance échouée pour X »
parce que X a été planifié puis annulé. C’est comme un chef de projet qui vous dit « la démo est annulée » sans mentionner la panne de courant.

Commencez par « systemctl –failed », mais ne vous arrêtez pas là

systemctl --failed est nécessaire mais pas suffisant. Il montre ce qui a fini en état d’échec. Mais l’unité qui compte peut être :

Une unité mount générée depuis fstab (quelquechose.mount).
Une unité device qui ne s’est jamais manifestée (pas d’état « failed » explicite ; plutôt un timeout).
Une unité one-shot qui a échoué tôt et s’est retrouvée enterrée dans les logs.

Préférez « critical-chain » à « blame » quand vous suspectez un ordre

systemd-analyze blame liste le temps passé par les unités, utile pour les démarrages lents. Mais il peut vous induire en erreur si une unité a passé du temps à attendre une autre unité. La chaîne critique vous montre le vrai chemin de dépendance vers une target.

Si vous êtes bloqué au démarrage et que quelque chose attend indéfiniment, demandez-vous :

Quelle target j’essaie d’atteindre ? Habituellement multi-user.target sur des serveurs.
Quelle unité est la dernière dans la chaîne critique ?
Qu’attend cette unité ? (status + journal)

Comprendre les trois axes de dépendance : exigence, ordonnancement, et relation

systemd a des relations qui sonnent de façon similaire mais se comportent différemment :

Requires= : si l’unité requise échoue, cette unité échoue.
Wants= : dépendance faible ; l’entraîne mais ne fait pas échouer le dépendant si elle échoue.
After=/Before= : ordonnancement seulement. Pas d’exigence.

Beaucoup d’incidents « dépendance échouée » viennent d’administrateurs ajoutant After= sans Wants= ou Requires=, en s’attendant
à ce que systemd démarre quelque chose automatiquement. Ce n’est pas le cas.

Quand le coupable réel est un point de montage ou un périphérique

Si un service a RequiresMountsFor=/var/lib/vz (ou une dépendance implicite via l’utilisation d’un chemin), et que ce montage est manquant, systemd refusera
de le démarrer. Le service n’est pas « cassé ». Il se comporte correctement.

Le meilleur truc : inspecter le statut de l’unité .mount et ses logs. C’est souvent plus explicite que le log du service.

Quand le vrai coupable est un timeout

Certaines apparitions de « Dépendance échouée » apparaissent parce qu’une dépendance n’a pas échoué explicitement—elle n’est jamais devenue active.
Par exemple : une unité device n’apparaît pas car un disque n’a pas été énuméré. Alors un mount attend, expire, échoue, et cela fait échouer un service.

Dans ces cas, les lignes importantes de log sont plus anciennes : messages du noyau, udev, erreurs du pilote de stockage, ou délais firmware. N’ignorez pas dmesg.

cr0x@server:~$ dmesg --level=err,warn | tail -n 30
[    7.112345] sd 2:0:0:0: [sdc] tag#23 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[    7.112400] blk_update_request: I/O error, dev sdc, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Décision : si vous voyez des erreurs de transport, arrêtez d’éditer des unités systemd et commencez à vérifier les câbles/HBA/état des disques.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster Proxmox à deux nœuds sur des sites distants. Les nœuds étaient stables, ennuyeux, et peu modifiés—jusqu’à un rafraîchissement du réseau.
L’équipe a remplacé un switch et ajusté des VLANs. Les nœuds sont revenus, mais l’un est resté « à moitié démarré ». La console affichait « Dépendance échouée pour PVE API Proxy Server. »
Naturellement, la première réaction fut de redémarrer pveproxy. Puis pvedaemon. Puis corosync. Puis le nœud a été redémarré encore, parce que redémarrer est un mode de vie.

La mauvaise hypothèse : « pveproxy est en faute parce que les utilisateurs le remarquent. » Ce n’était pas le cas. Le vrai coupable était un override drop-in ajouté des mois auparavant
à pve-cluster.service forçant After=network-online.target et Wants=network-online.target.
Le changement de switch a retardé le DHCP sur un VLAN de gestion qui n’aurait jamais dû être DHCP.

systemd-networkd-wait-online attendait une adresse qui n’est jamais arrivée. Cela a empêché network-online.target,
qui a empêché pve-cluster, qui a empêché pmxcfs de monter /etc/pve, ce qui a empêché pveproxy de lire la configuration.
Le message « Dépendance échouée » était exact, mais accusait le mauvais témoin.

La correction fut peu glamour : supprimer l’override, revenir à une adresse statique pour l’interface de gestion, et accepter que « network.target » suffit
pour la plupart des services locaux. Ils ont aussi ajouté une vérification lors des changements réseau : confirmer que « online » signifie bien ce que vous pensez. Rarement le cas.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait pour habitude : accélérer le démarrage en « simplifiant les dépendances ». Quelqu’un avait remarqué que le nœud mettait 90 secondes à démarrer à cause d’un disque de sauvegarde manquant dans fstab. Ils ont ajouté nofail. Bon début. Puis ils sont allés plus loin et ont ajouté des timeouts agressifs partout,
y compris pour l’import ZFS, parce que « les timeouts, c’est mal ».

Ils ont aussi désactivé zfs-import-cache et compté sur l’import par scan, pensant que c’était « plus flexible ». Sur le papier, oui.
En pratique, l’import par scan a causé des retards occasionnels lorsque le timing multipath changeait après des mises à jour firmware. Parfois le pool s’importait quelques secondes plus tard,
ce qui était acceptable—sauf qu’ils avaient raccourci les timeouts des services de montage et des services qui en dépendaient.

Résultat : échecs de démarrage intermittents. Pas à chaque fois, ce qui est le pire genre. Les unités mount expiraient, ZFS finissait par s’importer, mais le système avait déjà
échoué des unités critiques. Un redémarrage réparait parfois, ce qui encourageait l’équipe à continuer de redémarrer jusqu’à ce que ça marche. Ce n’est pas de l’ingénierie de fiabilité ; c’est de la divination.

La voie de reprise a été d’annuler l’« optimisation » et de traiter les dépendances de démarrage comme un contrat. Si le stockage est requis, laissez-lui le temps d’être prêt.
Si un disque est optionnel, marquez-le optionnel, mais ne raccourcissez pas arbitrairement les timeouts pour des ressources requises. Les démarrages doivent être déterministes, pas une course.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe enterprise faisait tourner des nœuds Proxmox avec des miroirs ZFS et un petit LVM local pour du scratch. Leur politique :
chaque changement touchant aux dépendances de démarrage nécessitait une validation console, un snapshot des overrides de services, et un échantillon de log « golden boot » enregistré.
Les gens se plaignaient que c’était bureaucratique.

Puis une nuit d’astreinte arriva. Une mise à jour du noyau a entraîné un nouvel initramfs, et une compilation DKMS pour ZFS a échoué silencieusement à cause d’un paquet de headers manquant
après un changement de dépôt. Le nœud a redémarré et est tombé dans un état où les modules ZFS n’étaient pas disponibles tôt. L’import du stockage a échoué,
les unités mount ont échoué, les services Proxmox ont cascades.

La pratique ennuyeuse a payé. Ils ont comparé le « golden boot » au démarrage courant via journalctl -b -1 et ont vu la ligne d’échec DKMS dans l’exécution précédente.
Ils avaient aussi une liste sauvegardée des unités et overrides activés, donc ils ont pu écarter l’hypothèse « quelqu’un a changé les dépendances systemd ».

La résolution fut rapide : installer les headers manquants, reconstruire DKMS, régénérer initramfs, redémarrer. Pas de drame, pas de redémarrages aléatoires de services non concernés.
Le postmortem fut aussi ennuyeux : maintenir la politique. L’ennui est bon quand votre travail est d’empêcher les idées excitantes des autres de casser la production.

Erreurs courantes : symptôme → cause racine → correction

Voici la bibliothèque de motifs. Si vous reconnaissez le symptôme, évitez les conjectures.

1) « Dépendance échouée pour PVE API Proxy Server »

Symptôme : pveproxy/pvedaemon ne démarre pas ; interface web indisponible.
Cause racine : /etc/pve non monté (pmxcfs down), ou montages/stockage manquants.
Correction : vérifier pve-cluster.service et le montage pmxcfs ; corriger corosync/ordonnancement réseau seulement si les logs l’indiquent.

2) « Dépendance échouée pour ZFS Mount » ou « Failed to import ZFS pools »

Symptôme : services ZFS échouent ; montages manquants ; guests ne démarrent pas.
Cause racine : fichier cache manquant, pool renommé, chemins de périphériques changés, module ZFS absent dans initramfs, ou erreurs disque réelles.
Correction : confirmer les pools via zpool import, importer manuellement pour le diagnostic, reconstruire le cache, assurer que les services d’import et l’initramfs sont corrects.

3) Le démarrage se bloque ~90 secondes sur « A start job is running … »

Symptôme : long délai au démarrage ; parfois se termine par des dépendances échouées.
Cause racine : service wait-online attendant une interface, ou montage fstab attendant un disque manquant.
Correction : identifier l’unité en attente avec systemd-analyze critical-chain ; désactiver ou configurer correctement wait-online ; marquer les montages non essentiels avec nofail.

4) Échecs liés au cluster après renommage de NIC ou changement matériel

Symptôme : corosync.service échoue ; pve-cluster échoue ; le nœud ne rejoint pas le cluster.
Cause racine : corosync configuré pour une interface dont le nom n’existe plus.
Correction : corriger la config de l’interface ring corosync et redémarrer corosync/pve-cluster dans le bon ordre ; éviter d’attacher à des noms d’interface instables.

5) « Dépendance échouée pour les systèmes de fichiers locaux »

Symptôme : le système tombe en shell d’urgence ; plusieurs services sont annulés.
Cause racine : un montage fstab requis a échoué (UUID erroné, erreurs fs, périphérique manquant).
Correction : corriger fstab, ajouter nofail pour les montages non essentiels, lancer fsck si nécessaire, ou résoudre le problème disque sous-jacent.

6) Après une mise à jour du noyau, l’import du stockage échoue de façon intermittente

Symptôme : services ZFS/LVM échouent seulement après certaines mises à jour ; roulette de redémarrage.
Cause racine : échec de build DKMS ou initramfs manquant un module/firmware.
Correction : vérifier le statut DKMS, reconstruire l’initramfs, s’assurer que les headers correspondent au noyau, confirmer la présence du module via lsinitramfs.

Listes de contrôle / plan étape par étape (sûr, ennuyeux, efficace)

Checklist A : Trouver la vraie unité en échec

Exécuter systemctl --failed. Notez les unités en échec.
Exécuter journalctl -b -0 -p err..alert. Trouver la première ligne « Failed to start … ».
Inspecter cette unité : systemctl status UNIT -l.
Si l’unité « failed » est un service feuille (UI, firewall), remontez les dépendances : systemctl list-dependencies --reverse.
Utiliser systemd-analyze critical-chain multi-user.target pour confirmer ce qui a réellement bloqué l’atteinte de la target.

Checklist B : Si ça sent le stockage

Vérifier si pools/VG existent : zpool import, vgs, pvs (si applicable).
Rechercher des échecs d’unités mount : systemctl --failed | grep mount, puis systemctl status *.mount au besoin.
Valider les montages critiques Proxmox : findmnt /var/lib/vz et tout ce qui contient les disques VM.
Scanner les logs noyau pour erreurs de transport : dmesg --level=err,warn.
Ensuite seulement envisager un import/activation manuel. Si l’import manuel fonctionne, corriger l’ordonnancement/la config ; ne « réparez » pas des pools sains par ennui.

Checklist C : Si ça sent le network-online ou le cluster

Vérifier les délais de démarrage : systemd-analyze blame et systemd-analyze critical-chain.
Voir qui entraîne network-online : systemctl list-dependencies --reverse network-online.target.
Inspecter les overrides d’unités : systemctl cat pve-cluster.service (et toute unité suspecte).
Confirmer l’état de corosync : systemctl status corosync puis les logs si nécessaire.
Supprimer les dépendances « online » inutiles. Préférez network.target sauf si vous pouvez expliquer par écrit pourquoi « online » est obligatoire.

Plan étape par étape : Corriger sans empirer

Quand vous avez fini le diagnostic, corrigez comme un adulte :

Faire un seul changement à la fois. Si vous changez trois choses et que ça redémarre, vous n’avez rien appris.
Privilégier les drop-ins plutôt que modifier les fichiers unit vendor, mais ne conservez pas d’anciens drop-ins que personne ne connaît.
Après les changements, recharger systemd et redémarrer seulement les unités pertinentes.

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart zfs-import-cache.service zfs-mount.service
cr0x@server:~$ sudo systemctl restart pve-cluster.service pveproxy.service

Ce que signifie la sortie : si le redémarrage fonctionne maintenant, votre problème était d’ordre/ordonnancement, pas une panne fondamentale.
Si le redémarrage échoue encore, relisez les logs de l’unité—votre correction n’a pas trait à la condition d’échec réelle.

FAQ

1) Pourquoi systemd affiche-t-il « Dépendance échouée » pour la mauvaise chose ?

Parce qu’il affiche ce qu’il a annulé. La cause racine est généralement la première unité qui a échoué plus tôt dans la chaîne. Trouvez cette unité dans le journal.

2) Quel est le moyen le plus rapide de trouver la première unité en échec ?

journalctl -b -0 -p err..alert et cherchez la première entrée « Failed to start … ». Ensuite ouvrez les logs de cette unité avec journalctl -u.

3) Dois-je simplement redémarrer tous les services Proxmox ?

Non. Redémarrer la pile peut masquer des problèmes d’ordonnancement et provoquer l’échec au prochain redémarrage. Corrigez d’abord la dépendance (stockage/montage/réseau).

4) Est-ce que `After=network-online.target` est une bonne idée pour Proxmox ?

En général non. Cela ajoute des modes d’échec et des délais. Ne l’utilisez que si le service exige vraiment un réseau routable au démarrage, et que vous avez configuré le wait-online correctement.

5) Comment savoir si c’est du stockage ou de l’ordonnancement systemd ?

Si l’import/activation manuel fonctionne (les pools ZFS s’importent, les VG s’activent) et qu’il n’y a pas d’erreurs I/O dans le noyau, c’est probablement de l’ordonnancement/configuration. Si des périphériques manquent ou que dmesg montre des erreurs, c’est matériel/stockage.

6) Et si un disque de sauvegarde manquant dans fstab casse le démarrage ?

Rendez-le optionnel : ajoutez nofail et un court x-systemd.device-timeout=. Ou supprimez le montage et montez-le à la demande. Ne laissez pas un stockage optionnel devenir une porte d’entrée de démarrage.

7) Pourquoi `systemd-analyze blame` pointe-t-il parfois vers le mauvais goulot ?

Parce qu’il mesure le temps passé dans les unités, y compris le temps d’attente. Utilisez systemd-analyze critical-chain pour voir le vrai chemin de dépendance.

8) Si `/etc/pve` n’est pas monté, puis-je quand même récupérer le nœud ?

Oui, mais vous devez assurer la santé de pve-cluster/pmxcfs. Commencez par réparer corosync (si en cluster) et garantir les montages/stockages requis. Puis redémarrez pve-cluster.

9) « Dépendance échouée » peut-elle être causée par une dépendance circulaire ?

Oui. Surtout avec des overrides personnalisés qui forcent network-online ou des montages dans le mauvais sens. Cherchez des boucles d’ordonnancement dans les logs et utilisez systemctl cat pour trouver l’override qui l’a créée.

10) Quelle est la façon la plus sûre de modifier des dépendances systemd ?

Utilisez un drop-in sous /etc/systemd/system/UNIT.d/override.conf, documentez pourquoi, et testez un redémarrage. Si vous ne pouvez pas le justifier, ne le déployez pas.

Conclusion : prochaines étapes à faire aujourd’hui

Le remède à « Dépendance échouée » n’est pas la superstition. C’est le traçage du graphe.
Trouvez la première unité en échec dans le journal, confirmez la chaîne de dépendance, et corrigez le bloqueur en amont—généralement l’import/montage de stockage, pmxcfs, ou network-online.

Prochaines étapes pratiques :

Sur un nœud sain, capturez une base : systemctl --failed (doit être vide), systemd-analyze critical-chain, et overrides activés (systemctl cat pour les unités critiques Proxmox).
Auditez /etc/fstab pour les montages non essentiels et marquez-les optionnels ou montables à la demande.
Recherchez et supprimez les drop-ins « mystères » qui forcent network-online.target sans raison valable.
Après les mises à jour du noyau, vérifiez que les modules de stockage sont présents dans l’initramfs avant de programmer des redémarrages.