Proxmox pvedaemon.service en échec : pourquoi les tâches ne démarrent pas et comment réparer

novembre 25, 2025 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

Vous cliquez sur Démarrer pour une VM. L’interface web fait comme si elle avait soumis le travail. Puis rien ne se passe — pas de journal de tâche, pas d’erreur exploitable, juste un long silence et la sensation croissante que l’hyperviseur vous juge.
Si pvedaemon est arrêté, Proxmox peut sembler « globalement correct » alors que la seule chose dont vous avez besoin — les tâches — cesse tout simplement d’exister.

C’est l’un de ces échecs qui coûtent des heures parce qu’ils ne cassent pas bruyamment. Il casse poliment. Voici comment le diagnostiquer rapidement, le corriger correctement et l’empêcher de revenir comme une mauvaise réunion récurrente.

Ce que fait pvedaemon (et pourquoi l’interface ment quand il est mort)

Proxmox n’est pas un monolithe. C’est un ensemble de démons coopératifs et une interface web qui se contente de relayer des requêtes vers eux. Si vous retenez une chose :
pvedaemon est le worker qui exécute la plupart des tâches locales au nœud — démarrage/arrêt des invités, opérations de snapshot, sauvegardes, actions sur le stockage et plein d’autres jobs « faire un truc » déclenchés depuis l’UI ou l’API.

Quand pvedaemon est arrêté, l’interface web (pveproxy) peut continuer à servir des pages correctement. L’authentification fonctionne. Les tableaux de bord s’affichent. Vous pouvez même cliquer sur des boutons.
Mais lorsque le système tente de lancer une tâche, il ne peut pas la confier au worker. C’est pourquoi vous observez le comportement classique : UI vivante, tâches mortes.

En termes de fiabilité : votre plan de contrôle répond en HTTP, mais votre exécuteur manque à l’appel. C’est comme un restaurant qui prend des réservations alors que la cuisine est en feu.

À quoi s’attendre en cas de panne

Les entrées de journal de tâche n’apparaissent pas, ou apparaissent puis échouent instantanément avec « connection refused », « timeout » ou « no such file ».
Les sauvegardes ne s’exécutent pas à l’heure, ou démarrent et restent bloquées sur des verrous.
Démarrer une VM depuis le CLI (qm start) peut fonctionner si cela contourne certaines voies API, mais de nombreuses opérations dépendront toujours de l’écosystème de démons.
Les environnements en cluster ajoutent une couche de complexité : des tâches peuvent être soumises au mauvais nœud ou échouer à cause de l’état du cluster, même si l’UI semble saine.

Une citation utile en opérations — attribuée à Werner Vogels (CTO d’Amazon) : You build it, you run it. Si vous exploitez Proxmox en production, vous êtes aussi responsable de ce mode de panne.

Guide de diagnostic rapide

Ne « tatonnez » pas. Exécutez une séquence serrée qui restreint le domaine de la panne en quelques minutes. L’objectif est de répondre à trois questions :
Est-ce que pvedaemon est réellement arrêté ? Si oui, pourquoi ? Et s’il redémarre en boucle, qu’est-ce qui le tue ?

Première étape : confirmer le statut du démon et une boucle de redémarrage

Vérifiez systemctl status pvedaemon et journalctl -u pvedaemon.
Si vous voyez « start request repeated too quickly » ou des codes de sortie, vous êtes dans le monde de systemd. Corrigez l’erreur sous-jacente ; n’abusez pas des redémarrages.

Deuxième étape : vérifier « ce n’est pas pvedaemon, c’est tout ce qui est en dessous »

Espace disque plein sur le système racine ou /var/log.
Module Perl cassé / mise à jour de paquet interrompue.
Problèmes d’hôte / DNS / état du cluster empêchant les appels API.
Timeouts de stockage (NFS/iSCSI/Ceph) provoquant le blocage des tâches et donnant l’impression que pvedaemon est « gelé ».

Troisième étape : décider de la posture de récupération

Si c’est un plantage propre avec une erreur de log claire : corriger puis redémarrer.
Si c’est un blocage dû au stockage : arrêtez creuser ; stabilisez d’abord le stockage.
Si c’est une partition de cluster : évitez les « redémarrages aléatoires ». Réconciliez le quorum et la santé de corosync.

Blague #1 (courte et pertinente) : Si pvedaemon est arrêté, votre UI Proxmox devient un générateur de fonds d’écran très coûteux.

Faits et contexte intéressants (pourquoi cela échoue de façon surprenante)

Un peu de contexte accélère le dépannage parce que vous arrêtez d’attendre que Proxmox se comporte comme un service unique.
Voici des faits concrets qui comptent quand pvedaemon.service tombe :

Les tâches Proxmox sont orchestrées entre plusieurs démons — pveproxy pour l’UI/API, pvedaemon pour les workers, et souvent pvestatd pour le rafraîchissement des métriques.
La majeure partie de la logique de gestion Proxmox est implémentée en Perl. Un module Perl manquant après une mise à jour peut faire planter les démons au démarrage comme un plancher qui s’ouvre.
La limitation du taux de redémarrage par systemd marquera les services comme échoués même s’ils pourraient se rétablir — parce que systemd protège le nœud d’une boucle fork-bomb.
Proxmox VE a évolué depuis 2008 autour du stack « PVE » avec un fort accent sur le packaging Debian. Cela signifie que l’état des paquets compte : des paquets partiellement installés peuvent paralyser les services centraux.
Les journaux de tâches sont écrits sous /var/log/pve/, et un système racine plein peut empêcher la création de tâches d’une manière qui ressemble à une « panne aléatoire de démon ».
L’appartenance au cluster affecte le routage des tâches. Dans un cluster, certaines tâches consultent la config sous /etc/pve, qui est un système de fichiers distribué géré par pmxcfs.
/etc/pve n’est pas « juste un répertoire ». C’est un système de fichiers FUSE spécial. Si pmxcfs a des problèmes, les configs peuvent sembler manquantes ou obsolètes, et les démons peuvent planter en les lisant.
Les plugins de stockage peuvent bloquer les tâches de gestion. Si un serveur NFS se fige, une simple liste de sauvegarde peut bloquer jusqu’à ce que les timeouts se propagent.
Proxmox utilise des IDs de tâches (UPIDs) pour suivre les jobs. Si vous ne pouvez pas créer de UPID, vous avez généralement un problème de démon/journal/permission — pas un « problème de VM ».

Comment les pannes se manifestent : symptômes indiquant pvedaemon

On ne dépanne pas en devinant. On fait correspondre les symptômes aux domaines de panne probables.

Regroupements de symptômes classiques

L’interface web se charge, mais chaque action échoue : démarrage VM, arrêt VM, snapshot, sauvegarde. C’est pvedaemon ou un worker API qui est en faute, pas QEMU lui-même.
Les tâches apparaissent « en cours » indéfiniment : souvent des appels de stockage bloqués, contentions de verrou, ou un worker bloqué en I/O.
« Connection refused » ou erreurs API de type « 501 » : peuvent venir d’un pvedaemon arrêté, de pveproxy, ou de problèmes de permissions sur le socket local.
Après une mise à jour, les tâches s’arrêtent : incompatibilité de paquets, rupture de dépendances de modules Perl, ou services obsolètes non redémarrés proprement.
Sur un cluster, un seul nœud est bizarre : défaillance de service locale. Si tous les nœuds sont affectés : problème de quorum/cluster ou stockage partagé.

Tâches pratiques : commandes, sortie attendue et la décision à prendre

Ci-dessous des vérifications pratiques que j’exécute réellement. Chacune inclut : la commande, ce que signifie la sortie et la décision suivante.
Utilisez-les comme une procédure, pas comme un buffet.

Tâche 1 : Vérifier si pvedaemon est failed, dead ou en boucle de redémarrage

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-12-22 09:14:02 UTC; 2min 11s ago
    Process: 2190 ExecStart=/usr/bin/pvedaemon start (code=exited, status=255/EXCEPTION)
   Main PID: 2190 (code=exited, status=255/EXCEPTION)

Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Failed with result 'exit-code'.

Sens : Il n’est pas en cours d’exécution et il s’est arrêté immédiatement. C’est généralement une erreur de démarrage (config, dépendance manquante, permissions), pas une surcharge.

Décision : Allez directement aux journaux (journalctl) pour trouver la première erreur réelle. Ne redémarrez pas à l’aveugle.

Tâche 2 : Lire le journal de pvedaemon, mais faites-le sérieusement

cr0x@server:~$ journalctl -u pvedaemon -b --no-pager -n 200
Dec 22 09:14:02 server pvedaemon[2190]: Starting pvedaemon
Dec 22 09:14:02 server pvedaemon[2190]: Can't locate PVE/API2/Tasks.pm in @INC (you may need to install the PVE::API2::Tasks module) (@INC contains: /usr/share/perl5 ...)
Dec 22 09:14:02 server pvedaemon[2190]: BEGIN failed--compilation aborted at /usr/bin/pvedaemon line 7.
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION

Sens : Problème de packaging / dépendance. Perl ne trouve pas un module Proxmox. Cela arrive souvent après une mise à jour interrompue ou une installation partielle.

Décision : Ne perdez pas de temps à dépanner les « services » : réparez les paquets. Passez à la Tâche 8 (intégrité des paquets).

Tâche 3 : Vérifier si d’autres démons PVE sont aussi mal en point

cr0x@server:~$ systemctl --no-pager --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● pvedaemon.service     loaded failed failed PVE API Daemon
● pvestatd.service      loaded failed failed PVE Status Daemon

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.

Sens : Pas seulement un démon. Cela indique des dépendances partagées : pmxcfs, libs Perl, disque plein, config cassée ou mise à jour foirée.

Décision : Élargissez le périmètre : vérifiez pve-cluster/pmxcfs, le disque et les paquets avant de courir après un seul service.

Tâche 4 : Confirmer que le démon UI ne vous trompe pas

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:10 UTC; 25min ago
   Main PID: 1422 (pveproxy)
      Tasks: 4 (limit: 154606)
     Memory: 78.3M
        CPU: 6.321s
     CGroup: /system.slice/pveproxy.service
             ├─1422 pveproxy
             └─1427 "pveproxy worker"

Sens : Le proxy UI/API fonctionne. Les utilisateurs peuvent se connecter. Ils diront « Proxmox est opérationnel ». Ils ont techniquement raison, et c’est le pire genre de raison.

Décision : Concentrez-vous sur pvedaemon et la chaîne back-end (pmxcfs, stockage, paquets).

Tâche 5 : Vérifier la santé de pmxcfs et du système de fichiers du cluster (`/etc/pve`)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:07 UTC; 26min ago
   Main PID: 1201 (pmxcfs)
      Tasks: 7 (limit: 154606)
     Memory: 26.9M
        CPU: 2.113s
     CGroup: /system.slice/pve-cluster.service
             └─1201 /usr/bin/pmxcfs -l

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

Sens : Si pmxcfs n’est pas monté ou si pve-cluster est arrêté, de nombreuses configurations « disparaissent » et les démons peuvent planter en les lisant.

Décision : Si pve-cluster est en échec, réparez d’abord le système de fichiers du cluster ; redémarrer pvedaemon sera inutile.

Tâche 6 : Vérifier le quorum et corosync (nœuds en cluster)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Mon Dec 22 09:17:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          Yes

Sens : Si Quorum est No, le FS du cluster peut devenir en lecture seule ou obsolète et les opérations de gestion peuvent échouer ou se comporter étrangement.

Décision : Si non quorate, réparez d’abord le réseau/corosync. N’utilisez pas le « forcing » sauf si vous assumez le risque de split-brain et savez exactement ce que cela implique.

Tâche 7 : Vérifier l’espace disque et l’épuisement d’inodes (oui, vraiment)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        94G   94G     0 100% /

cr0x@server:~$ df -ih /var/log
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        6.0M  6.0M     0  100% /

Sens : Des disques pleins ou l’absence d’inodes peuvent empêcher l’écriture des logs, la création de journaux de tâches, la création de fichiers temporaires et même les opérations sur sockets. Les démons peuvent planter ou refuser de démarrer.

Décision : Libérez de l’espace immédiatement (rotation des logs, suppression d’anciennes sauvegardes sur le stockage local, vider le cache des paquets). Faites-le avant de redémarrer quoi que ce soit.

Tâche 8 : Valider la santé de dpkg/apt (classe « module manquant »)

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 pve-manager               Proxmox Virtual Environment management tools

cr0x@server:~$ apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following additional packages will be installed:
  pve-cluster pve-container pve-ha-manager
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/5,842 kB of archives.
After this operation, 24.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pve-cluster (8.0.7) ...
Setting up pve-manager (8.2.2) ...

Sens : Des paquets à moitié configurés sont un indice fort. Si des modules Perl manquent, les tâches échoueront de façon spectaculaire et répétée.

Décision : Remettez l’état des paquets propre (dpkg --configure -a, apt-get -f install) avant d’accuser systemd.

Tâche 9 : Essayer de démarrer pvedaemon manuellement et surveiller les erreurs immédiates

cr0x@server:~$ systemctl restart pvedaemon
cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:20:41 UTC; 3s ago
   Main PID: 3122 (pvedaemon)
      Tasks: 4 (limit: 154606)
     Memory: 64.2M
        CPU: 424ms
     CGroup: /system.slice/pvedaemon.service
             ├─3122 pvedaemon
             └─3123 "pvedaemon worker"

Sens : Le service a démarré et est resté opérationnel. C’est le cas facile.

Décision : Testez immédiatement une tâche simple (Tâche 12) puis recherchez le déclencheur initial (disque plein, paquet cassé, etc.) pour éviter une récidive.

Tâche 10 : Si ça plante encore, capturez la raison exacte de sortie

cr0x@server:~$ systemctl show -p ExecMainStatus -p ExecMainCode -p Result pvedaemon
ExecMainCode=1
ExecMainStatus=255
Result=exit-code

Sens : Le code de sortie 255 est courant pour une « exception au démarrage » dans des runtimes de haut niveau. Ce n’est pas assez informatif.

Décision : Il vous faut la première exception dans journalctl (Tâche 2) ou une vérification des paquets (Tâche 8).

Tâche 11 : Vérifier une pression mémoire excessive / tués par OOM

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 30
Dec 22 09:12:44 server kernel: Out of memory: Killed process 2877 (pvedaemon) total-vm:512004kB, anon-rss:221344kB, file-rss:1232kB, shmem-rss:0kB, UID:0 pgtables:624kB oom_score_adj:0
Dec 22 09:12:44 server kernel: oom_reaper: reaped process 2877 (pvedaemon), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Sens : Le noyau l’a tué. Pas systemd. Pas Proxmox. Le noyau. Généralement dû à un sur-engagement mémoire, une VM qui gonfle, ou l’épuisement du swap de l’hôte.

Décision : Corrigez la pression mémoire : réduisez le sur-engagement, ajoutez du swap (prudemment), arrêtez les invités problématiques et envisagez de réserver de la mémoire pour l’hôte. Redémarrer pvedaemon sans corriger la mémoire revient à tourner en boucle.

Tâche 12 : Valider l’exécution d’une tâche de bout en bout

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 3
[
  {
    "endtime": 1734868815,
    "id": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "node": "server",
    "pid": 4675,
    "starttime": 1734868780,
    "status": "OK",
    "type": "vzdump",
    "upid": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "user": "root@pam"
  }
]

Sens : Les tâches sont créées, suivies et terminées. Si votre UI continue d’avoir des problèmes, vous avez probablement un souci de cache/proxy UI — pas un worker.

Décision : Si cela fonctionne, attendez-vous à valider le stockage et ce qui avait initialement échoué (sauvegardes, migrations, snapshots).

Tâche 13 : Trouver une tâche bloquée et identifier quel worker la détient

cr0x@server:~$ ls -1 /var/log/pve/tasks | tail -n 5
UPID:server:00000A1C:00006D32:6767F1C0:qmstart:103:root@pam:
UPID:server:00000A21:00006DA0:6767F1E2:vzsnapshot:101:root@pam:
UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:
UPID:server:00000B15:00008260:6767F248:qmstop:102:root@pam:
UPID:server:00000B19:00008288:6767F251:qmstart:104:root@pam:

cr0x@server:~$ tail -n 50 "/var/log/pve/tasks/UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:"
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
ERROR: storage 'backup-nfs' is not online
INFO: backup job failed

Sens : Ce n’est pas « pvedaemon arrêté ». C’est « la tâche a tourné et a échoué ». Le journal indique quel sous-système réparer.

Décision : Arrêtez de déboguer les démons. Corrigez la connectivité/état du stockage.

Tâche 14 : Vérifier les verrous qui bloquent les tâches (commun avec les incidents de stockage)

cr0x@server:~$ pvesh get /cluster/locks
[
  {
    "lock": "backup",
    "node": "server",
    "type": "storage",
    "id": "backup-nfs",
    "time": 1734868001
  }
]

Sens : Un verrou existe. Les verrous ne sont pas forcément mauvais ; ils assurent la sérialisation. Mais des verrous obsolètes peuvent survenir après des crashs ou des timeouts.

Décision : Si le verrou est ancien et que la tâche est morte, confirmez qu’aucun processus actif ne tourne, puis supprimez-le en toute sécurité (voir Tâche 15). Ne supprimez pas les fichiers de verrouillage à l’aveugle.

Tâche 15 : Vérifier si une opération « bloquée » est toujours en cours avant de supprimer quoi que ce soit

cr0x@server:~$ ps aux | egrep 'vzdump|qemu-img|pvesm|pvedaemon' | grep -v egrep
root      3122  0.0  0.2  52440 18944 ?        Ss   09:20   0:00 pvedaemon
root      4675  0.1  0.3 120332 26420 ?        Ss   09:24   0:02 vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Sens : Le job est toujours en cours. Effacer les verrous maintenant serait une excellente façon de créer des sauvegardes qui se chevauchent et des snapshots incohérents.

Décision : Si c’est gelé, déboguez pourquoi (généralement I/O du stockage). Ne tuez le processus que si vous maîtrisez les conséquences (nettoyage de snapshot, archives partielles).

Tâche 16 : Confirmer l’état du stockage tel que Proxmox le voit (pas comme vous souhaiteriez)

cr0x@server:~$ pvesm status
Name         Type     Status     Total     Used     Available  %
local        dir      active     93.00G   12.40G     75.85G   13%
backup-nfs   nfs      inactive       0B       0B         0B    0%

Sens : Le stockage est inactif. Si des tâches en dépendent, elles échoueront ou resteront bloquées.

Décision : Dépannez le stockage au niveau OS : montages, réseau, identifiants. Ne blâmez pas pvedaemon pour refuser d’utiliser un stockage hors ligne.

Tâche 17 : Vérifier les montages NFS et la réactivité (exemple)

cr0x@server:~$ grep backup-nfs /etc/pve/storage.cfg
nfs: backup-nfs
        server 10.20.30.40
        export /srv/nfs/pve-backup
        path /mnt/pve/backup-nfs
        content backup
        options vers=4.1,proto=tcp

cr0x@server:~$ mount | grep /mnt/pve/backup-nfs || echo "not mounted"
not mounted

cr0x@server:~$ timeout 5 bash -lc 'ls -la /mnt/pve/backup-nfs'
ls: cannot access '/mnt/pve/backup-nfs': No such file or directory

Sens : Le chemin de stockage n’existe pas ou n’est pas monté. Proxmox le marque hors ligne, les tâches échouent. Si le chemin existe mais que ls bloque, vous avez un autre problème : un montage NFS bloqué.

Décision : Corrigez la définition/chemin de montage, et si les montages se bloquent, utilisez umount -f ou un démontage lazy avec prudence. Ne redémarrez pas un nœud pour réparer un montage à moins d’aimer les indisponibilités.

Tâche 18 : Vérifier les problèmes TLS/nom d’hôte (un tueur de tâches subtil)

cr0x@server:~$ hostname -f
server.example.internal
cr0x@server:~$ grep -E 'server|127.0.1.1' /etc/hosts
127.0.0.1 localhost
127.0.1.1 server.example.internal server

Sens : La résolution de nom est cohérente. Si ce n’est pas le cas — si hostname -f renvoie quelque chose qui ne correspond pas aux certificats ou à la config du cluster — vous pouvez voir des erreurs API étranges et de la confusion côté démons.

Décision : Corrigez hostname/DNS/hosts de manière cohérente sur tout le cluster. N’ajoutez pas « juste une entrée hosts de plus » avant d’être sûr que c’est la bonne solution. C’est ainsi qu’on crée des infrastructures hantées.

Causes profondes rencontrées en production

1) État des paquets cassé après une mise à jour (le plus courant)

Les mises à jour Proxmox sont généralement fluides — jusqu’à ce qu’elles ne le soient pas. Le mode de panne n’est pas toujours « mise à jour échouée ». Parfois la mise à jour « a presque marché » et vous laisse avec des modules Perl manquants, des paquets à moitié configurés ou des démons exécutant un ancien code contre de nouvelles bibliothèques.

L’indice : Can't locate ... in @INC, BEGIN failed, ou des plaintes dpkg audit. Réparez en complétant la configuration des paquets et en vérifiant que les dépôts correspondent à votre version Proxmox/Debian.

2) Disque plein ou épuisement d’inodes (silencieusement létal)

Proxmox écrit des journaux de tâches, l’état et des données temporaires. Si la racine est pleine, le symptôme est souvent « les tâches ne démarrent pas » ou « le service ne reste pas en route ».
Les gens aiment traiter les alertes d’espace disque comme optionnelles jusqu’à ce qu’elles deviennent obligatoires.

Déclencheurs courants : sauvegardes locales laissées sur le stockage local, journaux qui gonflent, dumps de crash, ou accumulation d’ISO.

3) Problèmes pmxcfs ou d’état du cluster

Dans un cluster, /etc/pve est le garde-manger des configurations. S’il est indisponible, les démons qui lisent la config peuvent planter ou mal fonctionner.
Si le quorum est perdu, vous pouvez voir des lectures obsolètes ou des écritures bloquées. Ce n’est pas de la fragilité : Proxmox refuse de mentir sur l’état distribué.

4) Timeouts de stockage et I/O bloquée (pvedaemon « up » mais inutile)

Vous pouvez avoir un pvedaemon en cours d’exécution qui est effectivement mort parce que ses workers sont bloqués en I/O. C’est particulièrement fréquent avec :

Montages NFS qui se bloquent au lieu d’échouer rapidement
iSCSI multipath mal configuré
Problèmes de santé Ceph (opérations lentes, requêtes bloquées)
Flapping de chemins Fibre Channel causant de longs timeouts SCSI

L’astuce est de distinguer : démon crashé vs démon bloqué. Les journaux et l’état des processus vous le diront.

5) Pression mémoire et tués par OOM

Quand le noyau commence à tuer des processus, il ne choisit pas celui que vous préférez. Si pvedaemon se fait tirer dessus, les tâches s’arrêtent. Mais le vrai problème est la gouvernance mémoire de l’hôte : ballooning, politique de swap, et le fait que « ça a démarré » n’est pas synonyme de « stable ».

6) Permissions et particularités du système de fichiers (les conteneurs compliquent)

Les problèmes de permissions apparaissent quand les journaux de tâches ne peuvent pas être écrits, quand un répertoire sous /var/lib a le mauvais propriétaire, ou quand quelqu’un a « durci » le nœud et cassé des hypothèses.
Proxmox n’est pas allergique au durcissement, mais il attend les bases : propriétaires corrects, chemins inscriptibles et options de montage sensées.

Trois mini-récits d’entreprise (parce que ça arrive toujours à « quelqu’un d’autre »)

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

Une entreprise de taille moyenne exploitait un cluster Proxmox à deux nœuds pour de la « haute disponibilité ». Pas HA-manager, juste un cluster. Leur hypothèse : « Deux nœuds, c’est redondant. »
L’équipe réseau a fait une modification de routine sur un switch core. Une courte tempête de broadcast plus tard, corosync a commencé à perdre des paquets.

Le nœud A servait toujours l’interface web. Les gens se sont connectés et ont tenté de redémarrer quelques VM « bloquées ». Les tâches ne s’exécutaient pas. Naturellement, quelqu’un en a conclu : « pvedaemon est cassé. »
Ils ont redémarré les démons. Ils ont redémarré tout le nœud. Rien n’a amélioré la situation, parce que le nœud était non-quorate et pmxcfs refusait de se comporter comme un système de fichiers mono-nœud.

La fausse hypothèse n’était pas sur pvedaemon. Elle concernait le quorum. Les clusters à deux nœuds sont une dette opérationnelle à moins que vous n’ayez conçu délibérément le comportement du quorum (witness, qdevice ou un troisième nœud).

La réparation n’a rien d’héroïque : restaurer la connectivité corosync, rétablir le quorum, confirmer la santé de /etc/pve, puis redémarrer proprement les services.
Ensuite, ils ont ajouté un dispositif de quorum. Ennuyeux. Efficace. Le seul type de « redondance » qui compte à 3h du matin.

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

Un autre service voulait des sauvegardes plus rapides. Ils ont basculé vzdump vers une cible NFS avec des options de montage agressives et des timeouts ajustés, parce que « les valeurs par défaut sont lentes ».
Ça a marché. Pendant un temps. Les sauvegardes étaient plus rapides quand le NAS était sain.

Puis le NAS a eu un basculement de contrôleur pendant la fenêtre de sauvegarde. L’export NFS n’est pas tombé proprement ; il est resté « à moitié vivant ». Les lectures fonctionnaient parfois. Les appels métadonnées se bloquaient.
Du point de vue de Proxmox, les tâches démarraient puis se figeaient. Les workers s’entassaient. pvedaemon restait en cours, mais toutes les files de tâches devenaient un parking.

L’« optimisation » a créé un système qui échouait en se bloquant, pas en échouant rapidement. C’est le pire mode de panne pour un ordonnanceur de tâches parce que ça consomme la capacité des workers sans fournir d’erreur utile.

La solution à long terme a été d’arrêter de traiter le stockage comme une boîte noire magique : ils ont ajouté de la supervision de la réactivité NFS (pas seulement du ping), changé le comportement de montage pour favoriser un échec rapide, et échelonné les sauvegardes pour réduire la zone d’impact.
Les sauvegardes sont un peu plus lentes. Les incidents sont beaucoup plus rares. Un compromis que la plupart des adultes acceptent.

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

Un environnement réglementé exploitait des clusters Proxmox avec une routine de maintenance stricte : avant les mises à jour, ils contrôlaient l’espace libre sur la racine, confirmaient la santé de dpkg et prenaient une sauvegarde de configuration de /etc/pve (plus une note des versions courantes).
Personne n’aimait cette checklist. C’était de la paperasserie avec des commandes shell.

Lors d’une fenêtre de mise à jour, un problème de miroir a causé des téléchargements partiels et laissé pve-manager à moitié configuré. pvedaemon n’a pas réussi à démarrer et les tâches se sont éteintes.
L’ingénieur d’astreinte n’a pas improvisé. Il a exécuté le plan ennuyeux : confirmer l’état des paquets, réparer les dépendances, relancer la configuration, redémarrer les démons dans un ordre propre.

Parce qu’ils disposaient d’une base connue (versions, espace, et une copie des configs), ils ont pu prendre des décisions rapides et sûres. Pas de devinettes. Pas de spirales « peut-être que c’est DNS ».
Les systèmes ont été rétablis rapidement, et le postmortem a été court, ce qui est un signe discret de satisfaction professionnelle.

Blague #2 (courte et pertinente) : La seule chose plus persistante qu’un verrou obsolète, c’est un dirigeant qui demande si vous « avez essayé de redémarrer ».

Erreurs courantes : symptôme → cause → correction

Cette section est directe volontairement. Ce sont les erreurs qui transforment une réparation de 10 minutes en un incident de moitié de journée.

1) « Les tâches ne démarrent pas, donc je redémarre tout le nœud »

Symptôme : L’UI fonctionne ; les tâches ne démarrent jamais ou échouent immédiatement.
Cause : pvedaemon a planté à cause de paquets manquants ou d’un disque plein ; un reboot ne corrige ni l’un ni l’autre.
Correction : Vérifiez systemctl status pvedaemon, puis journalctl -u pvedaemon, puis corrigez les paquets/disque avant de redémarrer.

2) « J’ai supprimé des verrous parce que ça semblait bloqué »

Symptôme : Sauvegardes/migrations bloquent ; des verrous apparaissent dans les locks du cluster.
Cause : Le job tourne toujours mais est bloqué sur le stockage ; supprimer le verrou crée des opérations qui se chevauchent.
Correction : Confirmez les processus avec ps et la réactivité du stockage. Ne supprimez les verrous que si vous avez prouvé que le worker est mort.

3) « Le stockage va bien parce que ping répond »

Symptôme : pvedaemon tourne mais les tâches se bloquent, surtout sauvegardes/snapshots.
Cause : NFS/iSCSI/Ceph se figent à la couche I/O ; ping est sans rapport.
Correction : Testez des opérations réelles : ls sur le montage, lecture/écriture de petits fichiers, vérifiez pvesm status, examinez les logs kernel pour timeouts I/O.

4) « J’ai mis à jour, c’est terminé, donc les paquets doivent être corrects »

Symptôme : pvedaemon sort avec des erreurs de module Perl.
Cause : Paquets à moitié configurés ou mismatch de dépôt.
Correction : dpkg --audit, dpkg --configure -a, apt-get -f install, puis redémarrez les services.

5) « C’est un nœud unique, le service de cluster n’a pas d’importance »

Symptôme : Les lectures de config échouent, /etc/pve semble incorrect, les tâches plantent en accédant à la config.
Cause : pmxcfs/pve-cluster arrêté même sur une installation « mono-nœud », car Proxmox l’utilise toujours pour la gestion de config.
Correction : Restaurez la santé de pve-cluster et confirmez que /etc/pve est monté en tant que fuse.pmxcfs.

6) « J’ai réparé le démon, mais les tâches ne démarrent toujours pas »

Symptôme : pvedaemon actif ; les actions UI continuent d’erreur ou de se bloquer.
Cause : Stockage sous-jacent hors ligne, verrou obsolète, ou routage API / mismatch de hostname.
Correction : Vérifiez les journaux de tâches dans /var/log/pve/tasks/, validez pvesm status et confirmez la cohérence hostname/DNS.

Listes de vérification / plan pas à pas

Checklist A : Rétablissement rapide de l’exécution des tâches (nœud unique)

Vérifiez l’espace disque et les inodes : df -h /, df -ih /. Libérez de l’espace si nécessaire.
Vérifiez le statut du service : systemctl status pvedaemon.
Consultez les logs : journalctl -u pvedaemon -b -n 200. Trouvez la première erreur réelle.
Si c’est l’état des paquets : lancez dpkg --audit, puis dpkg --configure -a, puis apt-get -f install.
Confirmez pmxcfs : systemctl status pve-cluster et mount | grep /etc/pve.
Redémarrez dans l’ordre raisonnable :
- systemctl restart pve-cluster (si nécessaire)
- systemctl restart pvedaemon
- systemctl restart pveproxy (optionnel, si l’UI reste étrange)
Validez avec pvesh get /nodes/$(hostname)/tasks --limit 3 et une opération réelle de test (démarrer/arrêter une VM non critique).

Checklist B : Rétablissement sûr en cluster (éviter d’empirer)

Vérifiez le quorum en premier : pvecm status.
Si non quorate : réparez le réseau corosync d’abord. Évitez les redémarrages aléatoires.
Confirmez que /etc/pve est monté et cohérent sur le nœud que vous utilisez.
Consultez les logs pvedaemon pour des erreurs de lecture de config ou de permissions.
Vérifiez l’état du stockage depuis le nœud où les tâches échouent : pvesm status.
Ce n’est qu’après tout cela : redémarrez pvedaemon sur le nœud affecté et retestez les tâches.

Checklist C : Prévenir la récurrence (la partie que la plupart des équipes sautent)

Placez des alertes d’espace libre de la racine là où des humains les voient, et agissez dessus.
Après les mises à jour, vérifiez la santé des démons : systemctl is-active pvedaemon et lancez une tâche de test.
Faites en sorte que le stockage « échoue rapidement » lorsque possible, et surveillez la réactivité du stockage (pas seulement la disponibilité).
Documentez comment votre cluster gère le quorum (surtout s’il n’a que deux nœuds).
Conservez un plan de rollback connu pour les paquets : caches de paquets, miroirs locaux, ou au moins une procédure de récupération testée.

FAQ

1) Qu’est-ce qui casse exactement quand pvedaemon est arrêté ?

La plupart des tâches de gestion locales au nœud : actions de cycle de vie VM/LXC, sauvegardes, snapshots, nombreuses opérations de stockage et tout ce qui nécessite un worker de tâche et le suivi UPID.

2) Pourquoi l’interface web se charge-t-elle encore si pvedaemon est en échec ?

Parce que pveproxy sert l’UI et le front-end API. Il peut répondre même si le worker back-end manque. L’UI n’est pas malveillante ; elle est juste optimiste.

3) Comment distinguer « pvedaemon a planté » et « pvedaemon est gelé » ?

Si systemd affiche failed ou inactive, il a planté ou n’a pas démarré. S’il est active (running) mais que les tâches se bloquent, vérifiez l’I/O de stockage, les verrous et les processus worker.

4) Je vois « Can’t locate … in @INC » dans le journal. Et maintenant ?

Réparez l’état des paquets. Exécutez dpkg --audit, puis dpkg --configure -a et apt-get -f install. Ce n’est presque jamais résolu en éditant au hasard des chemins Perl.

5) Puis-je simplement réinstaller pve-manager ?

Parfois oui, mais considérez cela comme un problème de santé des paquets, pas d’un paquet isolé. Une réinstallation forcée sans résoudre le mismatch de dépôt ou les mises à jour partielles peut aggraver la situation.

6) Les tâches sont bloquées et je vois des verrous. Est-il sûr de les supprimer ?

Seulement après avoir confirmé que le processus sous-jacent n’est pas en cours d’exécution et que le sous-système de stockage est stable. Les verrous existent pour prévenir la corruption ; les supprimer à l’aveugle, c’est jouer avec vos données.

7) Des problèmes DNS/hostname peuvent-ils réellement provoquer des échecs de tâches ?

Oui, surtout dans les clusters où les nœuds se référencent entre eux par nom et valident des certificats. Une résolution de nom incohérente peut provoquer des erreurs API, des migrations et des opérations de stockage qui échouent de façon apparemment non liée.

8) Redémarrer pveproxy aide-t-il quand les tâches ne démarrent pas ?

Rarement. Si pvedaemon est mort, redémarrer le proxy UI est une mise en scène. Redémarrez pvedaemon après avoir corrigé la cause, et ne redémarrez pveproxy que si l’UI met en cache des erreurs ou se comporte bizarrement.

9) Est-ce lié spécifiquement aux sauvegardes vzdump ?

Les sauvegardes sont un déclencheur fréquent car elles sollicitent fortement le stockage et créent des verrous. Mais la défaillance de pvedaemon est plus large : tout échec de l’ordonnanceur de tâches affectera de nombreuses opérations.

10) Quel est le test le plus rapide pour savoir si c’est réparé ?

Lancez une tâche inoffensive et rapide et confirmez qu’elle se termine. Par exemple, interrogez les tâches récentes avec pvesh et lancez un stop/start sur une VM non critique.
Si les tâches génèrent des UPIDs et se complètent, le chemin worker est revenu.

Conclusion : étapes suivantes qui tiennent

Quand pvedaemon.service échoue, Proxmox ne « tombe » pas tellement que l’infrastructure cesse de travailler. C’est pourquoi ça fait perdre du temps : les tableaux de bord continuent de s’afficher, les utilisateurs continuent de cliquer, et rien ne se passe réellement.

Faites ceci ensuite, dans cet ordre :

Confirmez le mode de panne : crash vs gel (systemctl status, journalctl).
Corrigez les suspects habituels : disque/inodes, état des paquets, pmxcfs/quorum, réactivité du stockage.
Redémarrez délibérément : redémarrez les bons démons dans le bon ordre, puis exécutez un test de bout en bout.
Prévenez la récurrence : alertez sur l’usage de la racine, vérifiez après les mises à jour et surveillez le stockage comme une partie de la pile compute — parce que c’en est une.