Le système note en permanence ce qu’il fait dans des journaux. Quand quelque chose ne fonctionne pas, c’est là que se trouve l’explication : quel service a échoué, à quel moment, et pourquoi.
Tout y est regroupé, quel que soit le service concerné : une seule commande, journalctl, permet de tout consulter.
Vous n’avez pas besoin de tout comprendre. Repérer le moment du problème et copier les quelques lignes correspondantes suffit largement pour demander de l’aide.
Cette page se consulte en SSH (voir Accès SSH).
journalctl -f
Les lignes s’affichent au fur et à mesure que le système les écrit. C’est très pratique pour reproduire un problème : lancez cette commande, provoquez le dysfonctionnement, et regardez ce qui apparaît.
Appuyez sur Ctrl + C pour arrêter l’affichage.
journalctl -u NOM_DU_SERVICE
Pour retrouver le nom d’un service, voyez la page Services.
Ajoutez -f pour suivre ce service en direct :
journalctl -u NOM_DU_SERVICE -f
Les journaux sont volumineux. Pour ne voir que ce qui s’est passé récemment :
journalctl --since "1 hour ago"
journalctl --since today
journalctl --since "2026-07-25 14:00"
Et pour ne garder que les erreurs :
journalctl -p err --since today
Pour voir ce qui s’est passé au dernier démarrage :
journalctl -b
Et au démarrage précédent, utile quand la machine a redémarré toute seule :
journalctl -b -1
Pour transmettre des journaux au forum ou à un rapport d’anomalie, enregistrez-les dans un fichier :
journalctl -b > /tmp/journal.txt
Puis récupérez ce fichier sur votre ordinateur :
scp root@ADRESSE_DE_VOTRE_SERVEUR:/tmp/journal.txt .
Précisez toujours l’heure approximative à laquelle le problème s’est produit : c’est ce qui permet de retrouver les bonnes lignes dans un journal qui en contient des milliers.
Relisez ce que vous publiez : les journaux peuvent contenir des adresses, des noms d’équipements, parfois des identifiants. Retirez ce que vous ne souhaitez pas rendre public.
Rien de particulier à retenir : les services qui tournent en containers écrivent dans le même journal que le reste du système. La commande vue plus haut fonctionne pour eux à l’identique :
journalctl -u zigbee2mqtt
Voir Services et modules.
Par défaut, le serveur Calaos ne consigne que l’essentiel. Quand on cherche la cause d’un problème précis, on peut lui demander d’être beaucoup plus bavard :
calaos_config set debug_enabled true
calaos_config set debug_level 4
systemctl restart calaos-server
Il est aussi possible de cibler un domaine particulier, pour éviter d’être noyé sous les messages. Chaque domaine reçoit son propre niveau :
calaos_config set debug_domains ota:5,remote_ui:5,remoteui:5
Remettez ce réglage à false une fois le diagnostic terminé. Les journaux détaillés remplissent le disque vite, et rendent la lecture des journaux ordinaires beaucoup plus pénible.
calaos_config set debug_enabled false
systemctl restart calaos-server
Ces réglages sont listés sur la page calaos_config.
Les journaux sont stockés dans /var/log, qui est exclu des points de restauration. Concrètement : après un retour en arrière, les journaux de l’incident sont toujours là, et vous pouvez encore comprendre ce qui s’est passé. Voir Sous le capot.
Pour connaître la place occupée par les journaux, et la réduire si nécessaire :
journalctl --disk-usage
journalctl --vacuum-time=30d