Proxmox pveproxy.service en échec : 7 causes courantes et l’ordre de correction

Playbook de diagnostic rapide (faire ça en premier)

Votre objectif n’est pas de « redémarrer le service jusqu’à ce que ça marche ». Votre objectif est d’identifier le goulot d’étranglement en moins de cinq minutes :
s’agit-il de la configuration, du système de fichiers, du TLS, des services dépendants ou de l’état du cluster ?

Minute 0–1 : Est-ce seulement l’interface web, ou le nœud est-il réellement malade ?

• Confirmez que vous pouvez SSH sur l’hôte.
• Vérifiez si les VM tournent (ne présumez pas ; vérifiez).
• Vérifiez si le port 8006 écoute localement.

Minute 1–2 : Lire la raison réelle de l’échec

• systemctl status pveproxy -l pour la ligne d’erreur principale.
• journalctl -u pveproxy -b --no-pager pour le contexte complet.

Minute 2–3 : Éliminations rapides qui résolvent la moitié des incidents

• Disque plein : df -h et df -i (les deux importent).
• Dérive horaire : timedatectl (TLS déteste les voyages dans le temps).
• Sanité du nom d’hôte/IP : hostname -f, getent hosts $(hostname -f).

Minute 3–5 : Dépendances et système de fichiers du cluster

• pve-cluster est-il actif ? /etc/pve est-il réactif ?
• pvedaemon est-il actif ? Il échoue souvent pour la même raison sous-jacente.
• Si en cluster : vérifiez l’état du quorum/corosync avant de « réparer » la mauvaise chose.

L’ordre compte parce que certaines « corrections » anéantissent des preuves. Si vous redémarrez d’abord, vous effacez les journaux les plus utiles,
et vous pouvez transformer un hic récupérable de pmxcfs en un casse-tête de split-brain de cluster.

Faits et contexte intéressants (pourquoi ça casse comme ça)

• Fait 1 : pveproxy est un service Perl qui termine le HTTPS pour l’interface web Proxmox sur le port 8006, et il est pointilleux sur les certificats et les permissions des fichiers.
• Fait 2 : La configuration de cluster de Proxmox vit dans /etc/pve, soutenue par pmxcfs (un système de fichiers distribué basé sur FUSE). Si /etc/pve est bloqué, beaucoup de services « aléatoires » échouent.
• Fait 3 : Même sur un « cluster » mononœud (oui, ça existe), pmxcfs existe toujours. Les gens l’oublient et diagnostiquent mal comme « juste un service web ».
• Fait 4 : Les erreurs TLS sont disproportionnellement fréquentes après des changements de nom d’hôte parce que Proxmox émet des certificats node liés à cette identité.
• Fait 5 : Sur les systèmes basés Debian, « disque plein » peut se manifester par des échecs d’écriture de certificats, des échecs de fichiers PID et des échecs d’écriture de logs — donc l’erreur que vous voyez peut être un symptôme secondaire.
• Fait 6 : Les problèmes de quorum corosync n’arrêtent pas toujours les charges de travail. Ils bloquent souvent d’abord le plan de gestion, ce qui rend la panne plus visible qu’elle ne l’est réellement.
• Fait 7 : Proxmox centralise intentionnellement de nombreux paramètres dans /etc/pve pour que les nœuds du cluster convergent. C’est excellent pour l’exploitation — jusqu’à ce que le magasin de configuration soit indisponible.
• Fait 8 : Le port 8006 indisponible ne signifie pas « Proxmox est en panne ». Dans des incidents réels, les VM continuent de servir le trafic pendant que les humains paniquent parce que l’UI a disparu.
• Fait 9 : Beaucoup d’événements « service failed » sont causés par quelque chose d’externe au service : DNS, temps, système de fichiers, ou une dépendance. Blâmer pveproxy revient à accuser le détecteur de fumée d’avoir causé l’incendie.

L’ordre de correction approprié : cessez de deviner, commencez à réduire

Voici la séquence opinionnée qui minimise le temps d’indisponibilité et évite les dégâts collatéraux. Suivez-la même si vous « savez déjà »
ce qui s’est passé. Vous avez souvent tort, et les journaux ne mentent pas.

1. Stabiliser l’accès : SSH, confirmez que vous êtes sur le bon nœud, confirmez que les charges tournent.
2. Lire la raison de l’échec : systemctl status et journalctl. Ne redémarrez pas tout de suite.
3. Éliminer les « erreurs non forcées » : disque plein, épuisement d’inodes, dérive horaire, incohérence DNS/nom d’hôte.
4. Vérifier la santé du système de fichiers du cluster : pve-cluster, réactivité de /etc/pve, montage FUSE.
5. Vérifier le matériel de certificats et clés : existence des fichiers, permissions, dates d’expiration, et si l’identité du nœud a changé.
6. Valider les conflits de binding de port : quelque chose d’autre utilise 8006, ou processus résiduels.
7. Ce n’est qu’ensuite que vous redémarrez les services : redémarrez dans l’ordre des dépendances, et surveillez les journaux pendant l’opération.

Une citation pour rester honnête. Werner Vogels (CTO d’AWS) a une idée paraphrasée qui tombe bien en exploitation :
Tout échoue, tout le temps ; concevez et opérez comme si l’échec était normal. — Werner Vogels (idée paraphrasée)

Blague n°1 : Redémarrer en premier, c’est comme « réparer » le voyant moteur d’une voiture en retirant l’ampoule. Le tableau de bord a l’air parfait ; le moteur n’est pas d’accord.

7 causes courantes de pveproxy.service en échec (avec la correction appropriée)

Cause 1 : Disque plein (ou épuisement d’inodes) casse le plan de gestion

Si / est plein, pveproxy ne peut pas écrire de logs, de fichiers PID ou de fichiers temporaires. Si les inodes sont épuisés, vous pouvez avoir de « l’espace libre »
mais ne plus pouvoir créer de fichiers. Les deux génèrent des échecs qui ressemblent à du TLS, des permissions ou des plantages aléatoires de services.

Ordre de correction : libérez de l’espace de manière sécurisée, puis redémarrez les services. Ne supprimez pas de fichiers au hasard dans /etc/pve ou /var/lib/pve-cluster.

• Nettoyez les caches apt, les anciens noyaux (avec prudence), les vieux logs et les sauvegardes échouées.
• Vérifiez /var/log, /var/lib/vz, /rpool (ZFS) et toute cible de sauvegarde montée.

Cause 2 : Problèmes de pmxcfs / pve-cluster (blocage de /etc/pve)

Si /etc/pve est lent ou bloqué, les services qui lisent leur config depuis là se comportent mal. Parfois ils se figent ; parfois ils quittent.
Un indice classique : des commandes comme ls /etc/pve bloquent, ou pvecm status prend une éternité.

Ordre de correction : inspectez pve-cluster et l’état corosync/quorum (si en cluster), puis redémarrez les services de cluster avec précaution.

Cause 3 : Problèmes de certificats/clés (expirés, manquants, mauvaises permissions, ou nom d’hôte non concordant)

pveproxy est un point de terminaison HTTPS. Si la paire de clés est manquante, illisible ou se réfère à une identité qui ne correspond plus au nœud,
il peut échouer au démarrage ou démarrer mais afficher une interface brisée/blanche selon le comportement du client.

Ordre de correction : validez les fichiers et permissions d’abord ; régénérez les certificats seulement si vous comprenez pourquoi ils ont cassé.

Cause 4 : Résolution de nom d’hôte et dérive d’identité du nœud

Proxmox est sensible à l’identité du nœud car elle fait partie de l’appartenance au cluster, du nommage des certificats et des attentes API. Un changement négligent du nom d’hôte
(ou une panne DNS) peut se propager en « pveproxy failed » parce que d’autres composants refusent d’avancer avec une identité incohérente.

Ordre de correction : corrigez /etc/hosts / DNS d’abord, puis les certificats, puis les services.

Cause 5 : Conflit de binding sur le port 8006 ou processus résiduel

Parfois pveproxy ne peut pas se binder sur 8006 parce qu’un autre processus l’occupe — souvent un reverse proxy mal configuré, un service de test égaré,
ou une instance précédente qui ne s’est pas arrêtée correctement.

Ordre de correction : identifiez le processus qui utilise le port, arrêtez-le ou reconfigurez-le, puis démarrez pveproxy.

Cause 6 : État de package cassé ou mises à jour partielles

Une mise à jour à moitié terminée peut laisser des modules Perl, bibliothèques ou fichiers de configuration incohérents. Le symptôme : pveproxy échoue immédiatement
avec des erreurs de chargement de module, ou démarre mais lance des exceptions à l’exécution.

Ordre de correction : confirmez l’intégrité des paquets, réparez les problèmes dpkg, réinstallez les paquets concernés si nécessaire, puis redémarrez.

Cause 7 : Dérive horaire et bizarreries TLS/cookies

Si l’heure saute, les certificats paraissent « pas encore valides » ou « expirés », les sessions se comportent de façon étrange, et les navigateurs affichent des erreurs qui ressemblent à des bugs d’UI.
Les problèmes NTP peuvent aussi coïncider avec des événements d’alimentation ou la dérive d’heure des hôtes de virtualisation.

Ordre de correction : corrigez la synchronisation temporelle d’abord. Régénérer des certificats sans corriger l’heure est une excellente façon de perdre un après-midi.

Blague n°2 : La dérive temporelle est le seul bug qui peut faire « expirer » votre certificat dans le futur. Félicitations, vous avez inventé le voyage dans le temps — dommage pour le TLS.

Tâches pratiques : commandes, sorties attendues et la décision que vous prenez

Voici les tâches que j’exécute réellement. Pas parce qu’elles sont sophistiquées, mais parce qu’elles réduisent rapidement l’espace de recherche.
Chaque tâche inclut : la/les commande(s), ce que la sortie signifie, et la décision à prendre ensuite.

Tâche 1 : Confirmer l’état du service et capturer la ligne d’erreur principale

cr0x@server:~$ systemctl status pveproxy -l
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: failed (Result: exit-code) since Mon 2025-12-25 10:31:14 UTC; 2min 3s ago
    Process: 1234 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
   Main PID: 1234 (code=exited, status=255/EXCEPTION)

Dec 25 10:31:14 pve1 pveproxy[1234]: starting server
Dec 25 10:31:14 pve1 pveproxy[1234]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Sens : Ce n’est pas « l’UI est lente ». C’est un échec de démarrage dur. La ligne clé est l’erreur de chemin de fichier.
Décision : ne touchez pas encore aux ports ou aux pare-feu. Allez directement vérifier l’existence des certificats/clés et la santé de /etc/pve.

Tâche 2 : Lire le journal complet pour pveproxy pour ce boot

cr0x@server:~$ journalctl -u pveproxy -b --no-pager -n 200
Dec 25 10:31:14 pve1 pveproxy[1234]: starting server
Dec 25 10:31:14 pve1 pveproxy[1234]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 10:31:14 pve1 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Sens : Confirme que c’est cohérent et pas intermittent.
Décision : passez aux vérifications de fichiers et du système de fichiers du cluster.

Tâche 3 : Vérifier si quelque chose écoute sur le port 8006 localement

cr0x@server:~$ ss -ltnp | grep -E ':8006\s'

Sens : L’absence de sortie signifie généralement que rien n’écoute. Si vous voyez un processus, ce n’est peut-être pas pveproxy.
Décision : si quelque chose occupe 8006, passez au chemin conflit de port ; sinon concentrez-vous sur la raison pour laquelle pveproxy ne démarre pas.

Tâche 4 : Identifier le processus si 8006 est pris

cr0x@server:~$ ss -ltnp | grep -E ':8006\s'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("nginx",pid=2200,fd=12))

Sens : Nginx est sur 8006. C’est presque toujours incorrect sur un nœud Proxmox à moins d’avoir déplacé l’UI intentionnellement.
Décision : arrêtez ou reconfigurez nginx ; libérez 8006 ; puis démarrez pveproxy.

Tâche 5 : Vérifier l’espace disque et la disponibilité des inodes (les deux)

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

cr0x@server:~$ df -i /
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2     1835008 250000 1585008   14% /

Sens : L’espace est à 100%. Les inodes vont bien. Cela peut empêcher les services de démarrer.
Décision : libérez de l’espace avant de faire quoi que ce soit d’autre. Redémarrer n’aidera pas ; cela peut même empirer.

Tâche 6 : Trouver rapidement les plus gros consommateurs (sans supprimer à l’aveugle)

cr0x@server:~$ du -xhd1 /var | sort -h
1.2G    /var/cache
2.8G    /var/log
14G     /var/lib
18G     /var

Sens : L’utilisation principale est sous /var/lib (souvent images, sauvegardes ou DB du cluster) et les logs.
Décision : inspectez /var/log pour processus trop bavards ; videz le cache apt ; déplacez ou supprimez les anciennes sauvegardes de façon intentionnelle.

Tâche 7 : Inspecter les logs pour croissance incontrôlée et tronquer en sécurité

cr0x@server:~$ ls -lh /var/log | tail -n 10
-rw-r----- 1 root adm  12G Dec 25 10:20 syslog
-rw-r----- 1 root adm 1.1G Dec 25 10:20 daemon.log

cr0x@server:~$ sudo truncate -s 0 /var/log/syslog
cr0x@server:~$ sudo systemctl restart rsyslog

Sens : Un fichier syslog énorme peut remplir la racine. Tronquer conserve le descripteur de fichier (utile quand les démons le gardent ouvert).
Décision : après avoir libéré de l’espace, redémarrez pveproxy et ses dépendances ; puis corrigez la source du spam de logs.

Tâche 8 : Vérifier que /etc/pve est monté et réactif (santé de pmxcfs)

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

cr0x@server:~$ timeout 2 ls -la /etc/pve
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 10:25 local
drwxr-xr-x 2 root www-data 0 Dec 25 10:25 nodes
-rw-r----- 1 root www-data 0 Dec 25 10:25 .members

Sens : Le montage FUSE existe et le répertoire répond en moins de 2 secondes.
Décision : si ceci bloque ou dépasse le timeout, arrêtez de poursuivre sur les certificats — corrigez pve-cluster / l’état corosync.

Tâche 9 : Vérifier pve-cluster et corosync/quorum (nœuds en cluster)

cr0x@server:~$ systemctl status pve-cluster -l
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:05:01 UTC; 28min ago

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

Quorum information
------------------
Date:             Mon Dec 25 10:33:01 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.7a
Quorate:          Yes

Sens : Le système de fichiers du cluster est actif, le quorum est présent. Bien — votre problème est vraisemblablement local (disque, TLS, conflit de port, paquets).
Décision : poursuivez vers les vérifications de certificats/identité pour pveproxy.

Tâche 10 : Valider l’identité du nœud et la résolution de nom d’hôte

cr0x@server:~$ hostnamectl --static
pve1

cr0x@server:~$ hostname -f
pve1.example.internal

cr0x@server:~$ getent hosts $(hostname -f)
10.10.10.11     pve1.example.internal pve1

Sens : Le nom d’hôte se résout en IP. Si ceci ne renvoie rien ou la mauvaise IP, les composants Proxmox peuvent se comporter de façon étrange.
Décision : corrigez le DNS ou /etc/hosts en premier. Ne régénérez pas les certificats tant que l’identité n’est pas correcte.

Tâche 11 : Vérifier la synchro horaire et si l’heure est plausible

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-25 10:33:40 UTC
           Universal time: Mon 2025-12-25 10:33:40 UTC
                 RTC time: Mon 2025-12-25 10:33:39
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : L’heure est synchronisée. Si ce n’est pas le cas, les navigateurs et le TLS vont vous punir.
Décision : si l’heure est fausse, rétablissez NTP d’abord, puis retentez pveproxy. Ne courez pas après une expiration fantôme de certificat.

Tâche 12 : Vérifier que le certificat proxy Proxmox et la clé existent et sont lisibles

cr0x@server:~$ ls -l /etc/pve/local/pve-ssl.pem /etc/pve/local/pve-ssl.key
-rw-r----- 1 root www-data 3452 Dec 25 10:25 /etc/pve/local/pve-ssl.pem
-rw-r----- 1 root www-data 1704 Dec 25 10:25 /etc/pve/local/pve-ssl.key

Sens : Les fichiers existent. Les permissions montrent root et groupe www-data lisibles ; c’est typique pour les composants web.
Décision : si manquants, il faudra régénérer (après avoir confirmé que /etc/pve est sain et que le nom d’hôte est correct).

Tâche 13 : Vérifier rapidement les dates de validité et le sujet du certificat

cr0x@server:~$ openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -dates -subject
notBefore=Dec 25 10:25:01 2025 GMT
notAfter=Dec 24 10:25:01 2035 GMT
subject=CN = pve1.example.internal

Sens : Le certificat est valide pour la plage temporelle et lié au CN attendu.
Décision : si le CN est incorrect ou les dates incohérentes, corrigez le nom d’hôte/l’heure et régénérez les certificats.

Tâche 14 : Régénérer les certificats Proxmox (uniquement quand l’identité et /etc/pve sont corrects)

cr0x@server:~$ pvecm updatecerts --force
updating certificate for node pve1
generating SSL certificate... done

cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl status pveproxy -l
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:35:12 UTC; 2s ago

Sens : La régénération du certificat a réussi et le proxy fonctionne désormais.
Décision : validez l’accès localement, puis à distance ; si l’accès distant échoue, inspectez le pare-feu/LB/reverse proxy.

Tâche 15 : Confirmer que l’UI locale répond (en contournant le DNS et le réseau externe)

cr0x@server:~$ curl -kI https://127.0.0.1:8006/
HTTP/1.1 200 OK
server: pve-api-daemon/3.0
content-type: text/html; charset=utf-8

Sens : Localement le point de terminaison fonctionne. Si les utilisateurs ne peuvent toujours pas l’atteindre, c’est du réseau, du pare-feu ou un proxy en amont.
Décision : vérifiez le pare-feu de l’hôte, le pare-feu en bordure, et toute configuration de reverse proxy.

Tâche 16 : Vérifier si pvedaemon est sain (il partage souvent la même cause racine)

cr0x@server:~$ systemctl status pvedaemon -l
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Mon 2025-12-25 10:05:03 UTC; 30min ago

Sens : Si pvedaemon échoue aussi, attendez-vous à un problème plus large : /etc/pve, disque, paquets ou identité.
Décision : traitez-le comme une défaillance du plan de gestion, pas un incident d’un seul service.

Tâche 17 : Rechercher des problèmes dpkg/apt après des mises à jour

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 VE virtualization management suite

Sens : Une configuration partielle peut casser les services de façon étrange.
Décision : réparez l’état des paquets avant de poursuivre le débogage.

Tâche 18 : Réparer la configuration des paquets et redémarrer proprement

cr0x@server:~$ sudo dpkg --configure -a
Setting up pve-manager (8.2.2) ...
Processing triggers for man-db (2.11.2-2) ...

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

cr0x@server:~$ sudo systemctl restart pveproxy
cr0x@server:~$ systemctl is-active pveproxy
active

Sens : Vous avez restauré un état de paquet cohérent.
Décision : si les échecs persistent, retournez aux journaux — désormais les journaux sont fiables et ne sont pas des artefacts de code à moitié installé.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (DNS « ça ne peut pas être ça »)

Une entreprise de taille moyenne exploitait un cluster Proxmox à trois nœuds pour des services internes. Un matin, l’UI web d’un nœud a disparu :
le port 8006 ne répondait plus. L’ingénieur d’astreinte a supposé que c’était « un truc web » et s’est immédiatement concentré sur les règles du reverse proxy, car
un changement récent avait eu lieu sur un load balancer interne.

Le nœud était joignable par SSH, les VM tournaient, mais pveproxy ne démarrait pas. Les journaux mentionnaient des certificats,
ce qui a renforcé l’histoire « web/TLS ». Ils ont régénéré les certificats. Pas d’amélioration. Ils ont réinstallé pve-manager.
Toujours rien. À ce stade, c’était une panne de deux heures du plan de gestion de ce nœud, avec plusieurs « corrections » avortées qui
ont compliqué le retour en arrière.

La cause réelle était banale : un enregistrement DNS pour le FQDN du nœud avait été mis à jour dans le cadre d’un projet de renumérotation IP, mais un
résolveur interne continuait de servir l’ancienne adresse. Sur le nœud Proxmox, getent hosts $(hostname -f) renvoyait une IP inattendue.
Certains composants étaient convaincus d’une identité ; d’autres en voyaient une autre.

Une fois la résolution de nom corrigée de façon cohérente (et en s’assurant que /etc/hosts reflétait la réalité), ils ont régénéré les certificats
une dernière fois et pveproxy a démarré immédiatement.

La leçon n’était pas « le DNS est toujours le problème ». La leçon est que les vérifications d’identité appartiennent aux cinq premières minutes.
Si vous ne validez pas vos hypothèses tôt, vous passez le reste de l’incident à traiter des symptômes que vous avez vous-même créés.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (rétention des logs et racine pleine)

Un autre environnement « renforçait » l’hygiène opérationnelle. Quelqu’un a décidé d’augmenter la rétention des logs sur les nœuds Proxmox parce que
« nous n’avons jamais assez d’historique lors des incidents ». Objectif raisonnable. L’exécution était du genre qui fait boire les SRE et fixer le vide.

La rétention a été effectivement augmentée en désactivant la rotation pour certaines unités bruyantes et en augmentant les tailles du journal. Ça a très bien marché
jusqu’à ce qu’une rafale de latence de stockage déclenche des messages de reconnexion iSCSI répétés sur plusieurs nœuds. Le débit de logs est passé de « bavard »
à « torrent », et les volumes racine se sont remplis pendant la nuit.

Quand / s’est rempli, pveproxy n’a pas pu démarrer au redémarrage car il ne pouvait pas écrire ce dont il avait besoin. L’équipe a couru après
TLS et les paquets car les erreurs visibles mentionnaient des opérations sur des certificats et des fichiers. Ils n’avaient pas tort — ces opérations échouaient.
Ils n’étaient simplement pas la cause initiale.

La correction a été simple : libérer de l’espace, redémarrer les services. La correction à long terme était aussi simple, mais nécessitait de la discipline :
politiques de rotation des logs qui anticipent des débits en pire scénario, plus surveillance de l’espace disque et des inodes, avec alertes avant 95% et avant que
le journal ne dévore l’hôte.

L’optimisation s’est retournée contre eux parce qu’elle a changé un mode de panne : de « nous manquons de contexte » à « nous avons perdu le plan de gestion ».
En exploitation, les problèmes les plus coûteux viennent souvent d’améliorations bien intentionnées qui n’ont pas été testées en charge.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (redémarrages dans l’ordre des dépendances et préservation des preuves)

Une équipe de services financiers exploitait des nœuds Proxmox sous contrôle de changement strict. Leurs runbooks n’étaient pas tape-à-l’œil. Ils n’étaient pas « innovants ».
Ils étaient corrects, et ils étaient pratiqués.

Pendant une fenêtre de maintenance électrique, un nœud est revenu avec pveproxy en échec. L’ingénieur d’astreinte n’a pas redémarré à nouveau.
Il n’a pas réinstallé. Il n’a pas régénéré les certificats par habitude. Il a suivi le runbook : capturer systemctl status,
capturer journalctl, vérifier le disque, vérifier l’heure, vérifier la réactivité de /etc/pve, puis vérifier les conflits de port.

Ils ont trouvé que /etc/pve était monté mais se bloquait de façon intermittente à cause d’un état pve-cluster bloqué après l’événement d’alimentation.
Le cluster était quoré, mais le processus local du système de fichiers du cluster d’un nœud était malheureux. Redémarrer les services dans le mauvais ordre aurait
fait basculer le nœud entre des états « semi-disponibles ».

Ils ont redémarré pve-cluster proprement, vérifié la réactivité de /etc/pve, puis redémarré pvedaemon, puis pveproxy.
L’UI est revenue, et l’incident s’est terminé avec une traçabilité complète qui a facilité le postmortem.

Rien d’héroïque. C’était le but. La pratique ennuyeuse — réparer les dépendances d’abord et préserver les preuves — a gardé la panne courte
et a empêché qu’une « correction » ne devienne un incident secondaire.

Erreurs courantes : symptôme → cause racine → correctif

1) « 8006 ne répond pas » → Vous supposez le pare-feu → C’est pveproxy qui n’écoute pas

Symptôme : Le navigateur ne peut pas se connecter à https://node:8006.

Cause racine : pveproxy est arrêté ; le port n’est pas lié.

Fix : Lancez ss -ltnp | grep :8006. Si vide, lisez journalctl -u pveproxy et corrigez la vraie erreur de démarrage.

2) « pveproxy échoue avec une erreur de certificat » → Vous régénérez les certificats immédiatement → La vraie source est /etc/pve bloqué

Symptôme : Erreurs sur /etc/pve/local/pve-ssl.pem manquant ou illisible.

Cause racine : pmxcfs est malsain ; /etc/pve n’est pas accessible, donc les fichiers « disparaissent ».

Fix : Validez mount | grep /etc/pve et timeout 2 ls /etc/pve ; corrigez pve-cluster d’abord.

3) « L’UI est vide » → Vous incriminez le cache du navigateur → L’heure du nœud est fausse

Symptôme : Avertissements TLS, comportements de session étranges, boucles de connexion.

Cause racine : Dérive de l’horloge ; les contrôles de validité TLS échouent et les cookies se comportent mal.

Fix : timedatectl ; rétablissez NTP ; puis redémarrez pveproxy si nécessaire.

4) « Le service ne démarre pas après une mise à jour » → Vous réinstallez des paquets au hasard → dpkg est à moitié configuré

Symptôme : Échecs de démarrage immédiats, modules manquants, comportement incohérent après une mise à jour.

Cause racine : Mise à jour partielle ou configuration dpkg interrompue.

Fix : dpkg --audit, puis dpkg --configure -a et apt-get -f install.

5) « pveproxy démarre annonce adresse déjà utilisée » → Vous tuez des PID au hasard → Un autre service est lié intentionnellement

Symptôme : Échec de bind sur 8006.

Cause racine : Reverse proxy ou service de test lié à 8006.

Fix : Identifiez avec ss -ltnp, changez ce service sur un autre port, gardez Proxmox sur 8006 sauf raison forte.

6) « pveproxy en échec » → Vous redémarrez → Le système de fichiers racine est plein et le redémarrage n’a rien libéré

Symptôme : Le service échoue à chaque démarrage ; les logs se plaignent d’écriture de fichiers.

Cause racine : Disque plein / inodes pleins.

Fix : df -h et df -i, puis supprimer/tronquer en sécurité et définir des seuils de surveillance.

7) « Ça fonctionnait hier » → Vous ignorez les changements de nom d’hôte → Certificats et identité du cluster en désaccord

Symptôme : Incohérence CN de certificat, erreurs UI, nommage de nœud incohérent.

Cause racine : Nom d’hôte/FQDN changé sans mise à jour de /etc/hosts, du DNS et des certificats/config du cluster Proxmox.

Fix : Corrigez la résolution de noms d’abord, puis pvecm updatecerts --force, puis redémarrez pveproxy.

Listes de contrôle / plan pas à pas

Checklist A : Triage dans les dix premières minutes (nœud unique ou cluster)

1. SSH. Confirmez que vous êtes sur le bon nœud : hostname, ip a.
2. Capturer les preuves :
   • systemctl status pveproxy -l
   • journalctl -u pveproxy -b --no-pager -n 200
3. Vérifier s’il écoute : ss -ltnp | grep :8006.
4. Vérifier espace et inodes : df -h, df -i.
5. Vérifier l’heure : timedatectl.
6. Vérifier l’identité : hostname -f, getent hosts $(hostname -f).
7. Vérifier le système de fichiers du cluster : mount | grep /etc/pve, timeout 2 ls /etc/pve.
8. Si en cluster : pvecm status et systemctl status corosync.
9. Ce n’est qu’après ce qui précède : redémarrez les dépendances, puis pveproxy.

Checklist B : Ordre de redémarrage sûr (si vous suspectez des problèmes de dépendance)

1. Si /etc/pve est bloqué : corrigez pve-cluster en premier.
2. Ordre de redémarrage (typique) : pve-cluster → pvedaemon → pveproxy.
3. Vérifiez chaque étape avec systemctl is-active et consultez les journaux immédiatement en cas d’échec.

Checklist C : Réparation des certificats sans se faire de dégâts

1. Confirmer que le nom d’hôte et le FQDN se résolvent correctement (hostname -f, getent hosts).
2. Confirmer que l’heure est correcte (timedatectl).
3. Confirmer que /etc/pve est réactif (pas de blocages).
4. Inspecter les fichiers cert/clé existants et leurs permissions.
5. Régénérer : pvecm updatecerts --force.
6. Redémarrer pveproxy et vérifier avec curl -kI https://127.0.0.1:8006/.

Checklist D : Si vous suspectez une mise à jour partielle

1. Vérifier : dpkg --audit.
2. Réparer : dpkg --configure -a.
3. Corriger les dépendances : apt-get -f install.
4. Réinstaller seulement si nécessaire (ciblé, pas au hasard).
5. Redémarrer les services et re-vérifier les journaux.

FAQ

1) Mes VM sont-elles arrêtées si pveproxy est en échec ?

Généralement non. pveproxy est le proxy web/API. Les charges de travail peuvent continuer de tourner. Vérifiez avec qm list et pct list,
et contrôlez la santé des applications depuis l’extérieur.

2) Pourquoi un disque plein arrête-t-il l’interface web ?

Les services doivent écrire des logs, des fichiers PID, des caches et des fichiers temporaires. Quand / est plein, les démarrages échouent de façons qui semblent non liées.
Vérifiez df -h et df -i tôt.

3) Puis-je simplement changer le port de l’interface Proxmox depuis 8006 ?

Vous pouvez, mais ce n’est probablement pas une bonne idée. Changer le port complique l’automatisation, la documentation et la réponse aux incidents. Si vous devez le faire,
faites-le intentionnellement et documentez-le. Sinon, libérez 8006 et laissez Proxmox utiliser son port par défaut.

4) Quelle est la relation entre pveproxy et pvedaemon ?

pvedaemon fournit la logique API/backend ; pveproxy le met en avant via HTTPS. Quand le plan de gestion est cassé à cause de /etc/pve
ou de problèmes d’identité, les deux peuvent échouer ou mal se comporter.

5) Quand dois-je régénérer les certificats ?

Quand les certificats sont manquants, invalides ou discordants — et seulement après avoir confirmé que la résolution de nom et l’heure sont correctes, et que
/etc/pve est réactif. Utilisez pvecm updatecerts --force.

6) Mon navigateur dit que le certificat est invalide. Est-ce que pveproxy est cassé ?

Pas nécessairement. pveproxy peut fonctionner correctement mais présenter un certificat que votre navigateur ne reconnaît pas (auto-signé par défaut)
ou un certificat dont le CN ne correspond pas au nom d’hôte utilisé. Vérifiez avec openssl x509 et assurez-vous de vous connecter via le FQDN attendu.

7) Dans un cluster, le quorum affecte-t-il pveproxy ?

Indirectement, oui. La stabilité du quorum et de corosync affecte pmxcfs et le comportement de /etc/pve, ce qui impacte les services qui lisent la configuration depuis là.
Si vous n’êtes pas quoré, corrigez les problèmes d’appartenance au cluster avant de faire des redémarrages cosmétiques.

8) Que faire si /etc/pve est lent ou se bloque ?

Traitez cela comme l’incident principal. Vérifiez pve-cluster et l’état de corosync. Évitez d’éditer la configuration sous un /etc/pve bloqué ; cela peut aggraver l’incohérence.
Restaurez d’abord la santé du système de fichiers du cluster.

9) Dois-je redémarrer le nœud pour réparer pveproxy ?

Le redémarrage est le dernier recours, pas la première réponse. Il peut déverrouiller un processus coincé, mais il efface aussi des preuves volatiles et ne résout pas les causes racines
comme disque plein, DNS, paquets cassés ou synchro temporelle. Si vous redémarrez, capturez d’abord les journaux.

10) pveproxy fonctionne mais l’UI reste injoignable depuis mon poste. Et maintenant ?

Confirmez la santé locale avec curl -kI https://127.0.0.1:8006/. Si localement ça marche, le problème est sur le chemin réseau : règles de pare-feu, routage, VLAN,
reverse proxies en amont, ou appliances de sécurité d’entreprise effectuant de l’interception TLS.

Conclusion : étapes suivantes pour éviter les répétitions

Un pveproxy mort n’est que rarement « juste pveproxy ». C’est votre plan de gestion qui vous dit qu’une chose basique a cassé : stockage, identité, temps,
système de fichiers du cluster, ou intégrité des paquets.

Les prochaines étapes qui rapportent réellement :

• Ajouter une surveillance du disque racine et des inodes avec alertes avant 90–95% d’utilisation, pas à 100% quand les services sont déjà tombés.
• Standardiser les changements d’identité des nœuds : les changements de hostname/DNS exigent une procédure contrôlée, pas un « fix rapide » de nuit.
• Pratiquer l’ordre de correction en fenêtre de maintenance : collecter les journaux, valider /etc/pve, puis toucher aux certificats, puis redémarrer.
• Garder les mises à jour banales : éviter les upgrades partiels, maintenir l’état des paquets propre, et ne pas mélanger les dépôts sans plan.
• Documenter tout comportement de port/proxy non par défaut pour que le prochain incident ne commence pas par une chasse au trésor.

Quand pveproxy.service failed réapparaîtra — et il le fera — exécutez le playbook de diagnostic rapide, respectez l’ordre des dépendances, et n’effacez pas les preuves avec des redémarrages « utiles ».