notes/proxmox-8-vers-9
Proxmox 9 : chrony tombe, et le refus n'est pas dans le journal du noyau
Après le dist-upgrade, la synchro d'heure ne repart pas, et la trace qui explique pourquoi s'écrit ailleurs que là où tu la cherches.
- proxmox
- debian
- apparmor
Le dist-upgrade de 8.4.21 vers 9.2.18 se termine proprement. Tu contrôles les services, et chrony.service est en échec. Deux lignes dans son journal : Fatal error : Could not send notification to $NOTIFY_SOCKET, et plus haut Could not open /var/log/chrony/tracking.log : Permission denied. Tu relances pve8to9 --full, il te répond « No (active) time synchronisation daemon ». Ton hyperviseur tourne sans heure juste.
Trois pistes évidentes, toutes éliminées par test. Le seccomp -F 1 de /etc/default/chrony : même échec avec -F 0. Un systemd pas rechargé : PID 1 était déjà en 257. Le mécanisme de notification lui-même : un service jetable Type=notify lancé sous l'utilisateur _chrony notifie sans la moindre erreur.
La cause est dans AppArmor. Le noyau appliquait encore l'ancien profil de /usr/sbin/chronyd, celui d'avant la montée. Le fichier livré par trixie contient bien la ligne @{run}/systemd/notify w, qui autorise la notification, mais personne ne l'avait rechargé. Et le refus ne sort pas où on le cherche : sur un hôte où auditd tourne, les lignes AppArmor ne passent pas par journalctl -k, elles atterrissent dans /var/log/audit/audit.log, sous la forme apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/chronyd" name="/run/systemd/notify".
Le correctif tient en deux commandes : apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.chronyd, puis systemctl restart chrony. Un redémarrage de la machine aurait rechargé le profil de la même façon, sauf que l'heure reste fausse jusque-là, et que tu ne rebootes pas un hyperviseur pour ça.
Deux autres pièges de la même montée, sur le même thème du contrôle qui ment. Le garde-fou « il ne reste plus rien de bookworm » écrit en grep -r attrape pve-enterprise.list.dpkg-dist, un résidu qu'apt n'ouvre jamais : restreins la recherche à sources.list, *.list et *.sources. Et au redémarrage, les VM sans ordre de démarrage se lancent une par une, environ deux minutes d'écart ici : un contrôle lancé trop tôt les voit arrêtées et te fait croire à une casse. Mets ton pare-feu virtuel en tête avec qm set <id> --startup order=1,up=60.
Le réflexe à garder : devant un « Permission denied » d'un démon confiné, sur une machine où auditd tourne, tu lis audit.log avant de toucher à quoi que ce soit d'autre.