Dépannage

Ce guide organise le diagnostic par symptôme. Principe général : collecter d’abord des preuves avec des commandes en lecture seule, avant toute modification. À chaque étape, consignez les observations, les commandes, les codes de sortie et les différences entre résultats attendus et réels.

Équipement inaccessible par SSH

Diagnostiquez séparément chaque couche :

1. Vérifiez l’adresse dans l’inventaire des équipements ; des adresses proches ne sont pas interchangeables ;
2. Contrôlez successivement la résolution, le routage, l’accès au port SSH et l’authentification ;
3. En cas de perte soudaine d’accès, rapprochez l’incident des dernières mises à jour ou redémarrages et demandez si nécessaire une vérification locale du port série ou de l’état physique.

Échec de démarrage ou redémarrages répétés

1. Collectez la sortie de démarrage, les journaux précédents avec journalctl -b -1, la cause de réinitialisation du watchdog et les erreurs de système de fichiers ;
2. Identifiez l’étape : chargeur, noyau, basculement système, démarrage des services, watchdog ou application ;
3. Vérifiez bootcount : les échecs consécutifs déclenchent la récupération automatique, puis le retour arrière des partitions au seuil prévu. Voir Double système A/B et basculement ;
4. Consultez l’état de récupération avec jelina-info et jelina-auto-recovery --state.

Ne basculez pas manuellement les partitions et ne lancez pas de retour arrière avant d’avoir identifié la cause, pour ne pas perturber la récupération automatique.

État système dégradé, degraded

systemctl is-system-running
systemctl --failed --no-pager

Examinez chaque service en échec, puis les services essentiels. Un service facultatif propre à une plateforme peut échouer sans anomalie globale ; un service à exécution unique peut normalement être inactif après achèvement.

Mise à jour bloquée

1. Consultez l’état et la progression avec jelina-info --get ota_status --json et jelina-local-ota -s ;
2. Vérifiez si une mise à jour est en attente de confirmation : c’est un état prévu, pas un blocage ;
3. Examinez le service de l’agent et ses journaux ;
4. Vérifiez l’espace disque, l’installateur et ses processus ;
5. Contrôlez l’accès au paquet, l’horloge, la résolution DNS et les certificats ;
6. Déterminez si l’installation est déjà terminée et attend seulement un redémarrage ou un remontage.

Pendant le diagnostic, ne soumettez ni ne confirmez plusieurs fois la mise à jour et ne supprimez pas les marqueurs d’attente de redémarrage.

Application ou conteneur indisponible

Contrôlez séparément l’état souhaité, le téléchargement de l’image, la création du conteneur, la santé du processus, les ports, le pare-feu et l’application elle-même. Commandes utiles :

docker ps                # État des conteneurs
docker logs <nom-conteneur>      # Journaux des conteneurs

Ne recréez pas manuellement les conteneurs ou services gérés par le système avant d’avoir conservé les preuves.

Disque plein ou racine en lecture seule

1. Comparez l’occupation en espace et en inodes des partitions racine et de données avec df -hT et df -i ;
2. Vérifiez le mode racine temporaire avec jelina-enter-tmpfs-root --status. Voir Stockage et partition de données ;
3. Distinguez le fonctionnement normal en lecture seule, une défaillance de la partition de données et un montage incorrect de la couche de superposition.

Ne supprimez pas de répertoire système ou de paquets que vous ne connaissez pas. N’effectuez pas d’opérations métier en mode racine temporaire.

Échec d’enregistrement ou cloud hors ligne

1. Consultez l’état avec jelina-manual-register --check. Voir Enregistrement et connexion des équipements ;
2. Vérifiez si le mode hors ligne est activé ;
3. Contrôlez l’horloge, le DNS, le routage, les certificats et l’accès aux points de terminaison cloud ;
4. Examinez les états et erreurs du service d’enregistrement et de l’agent ;
5. Distinguez activation initiale incomplète, identifiants invalides, problème réseau et refus du cloud.

Service impossible à démarrer

Vérifiez dans l’ordre les conditions de démarrage, l’existence et les permissions du programme, l’interpréteur du script et la disponibilité des montages requis.

Heure ou résolution DNS incorrecte

• Une heure incorrecte se manifeste souvent par des erreurs de certificat ou d’authentification cloud : comparez l’heure système, l’horloge matérielle et les journaux de synchronisation ;
• Pour le DNS, examinez le service de résolution et la configuration de connexion ; ne remplacez pas manuellement les fichiers générés par le système.

Interface graphique indisponible

Un terminal SSH n’a généralement pas d’environnement de session graphique. Une variable d’affichage vide ne prouve pas une panne de l’interface :

1. Vérifiez l’activation globale et le périmètre de désactivation ;
2. Consultez les instances et sessions avec jelina-ui-ctl list et jelina-ui-ctl sessions ;
3. Vérifiez les sessions graphiques actives et examinez les processus et journaux dans l’environnement de l’utilisateur cible.

Historique utile pour les redémarrages

Certains équipements conservent des archives de performances et des journaux persistants permettant de reconstituer l’état avant redémarrage :

journalctl --list-boots              # Liste des démarrages
journalctl -b -1 -p warning..alert   # Journaux d’avertissement du démarrage précédent
ls -1t /var/log/atop | head          # Archive historique des performances

Pour attribuer un redémarrage inattendu, corrélez la liste des démarrages, les journaux précédents, la cause du watchdog, la durée de fonctionnement et l’historique des mises à jour ou basculements.

Documentation associée

• Questions fréquentes — Réponses courantes
• Double système A/B et basculement — bootcount et retour arrière
• Chien de garde — Surveillance système
• État et informations système — Commandes de consultation