Un service passe en maintenance sur un serveur Solaris, l’alerte tombe, et la première réaction est d’ouvrir /var/adm/messages pour chercher une aiguille dans une botte de foin. On perd du temps, on scrolle, on finit par redémarrer le service à l’aveugle. La commande svcs -xv existe précisément pour éviter ce scénario, et lire les messages d’erreur SMF de manière structurée change radicalement la vitesse de diagnostic.
Pourquoi svcs -xv remplace la lecture brute des logs SMF
Sur un système Solaris ou SmartOS, chaque service géré par SMF (Service Management Facility) possède un état, des dépendances et un historique de transitions. Quand on se contente de fouiller dans les fichiers de log classiques, on voit des lignes isolées sans contexte : un message d’erreur ne dit pas pourquoi le service a basculé en maintenance, ni quels autres services sont impactés en cascade.
A lire également : Vérification de la mémoire dédiée d'un ordinateur : étapes et astuces
svcs -xv corrèle automatiquement l’état du service, ses dépendances cassées et le message explicatif fourni par SMF. En une seule commande, on obtient le nom du service, son état (disabled, maintenance, degraded), la raison textuelle de cet état, et la liste des services dépendants qui ne tournent plus.
Les retours d’expérience récents sur Solaris 11 confirment un déplacement des pratiques de debug vers cette lecture structurée, combinée à svcprop pour aller chercher les propriétés précises d’une instance, plutôt que la lecture directe de /var/adm/messages.
A lire en complément : Tableau d'octet conversion : repères rapides pour gagner du temps
Décoder les états SMF : maintenance, degraded, disabled
Quand on lance svcs -a, chaque ligne affiche un état. Trois d’entre eux méritent une attention immédiate parce qu’ils signalent un problème actif ou latent.
Le cas maintenance
Un service en maintenance a tenté de démarrer et a échoué. SMF ne réessaiera pas tout seul. C’est le signal le plus courant et celui qui génère le plus de tickets.
En lançant svcs -xv svc:/nom/du/service, on obtient la ligne « Reason » qui indique la cause directe : un fichier de configuration manquant, un port déjà occupé, un binaire absent. Cette ligne pointe souvent vers une page de diagnostic Oracle (les URLs de type http://sun.com/msg/SMF-8000-xx) qui détaille la marche à suivre.
L’état degraded
Le service tourne, mais partiellement. Il rend un service limité. On le repère moins vite qu’un service en maintenance parce qu’il ne provoque pas toujours d’alerte visible côté utilisateur. Un service degraded peut masquer un problème de dépendance qui ne se révélera qu’au prochain redémarrage complet.
Le statut disabled
Ici, pas de panne : un administrateur a explicitement désactivé le service (ou il n’a jamais été activé). La sortie de svcs -xv affiche « Disabled by an administrator ». Si le service devrait tourner, un simple svcadm enable suivi du FMRI (Fault Managed Resource Identifier) du service suffit.
Messages d’erreur SMF et conformité sécurité sur Solaris 11.4
On ne lit plus les messages d’erreur SMF uniquement comme des indicateurs techniques. Sur Solaris 11.4, SMF est au cœur des exigences de conformité sécurité. Un service de logging désactivé ou un service de sécurité en maintenance constitue un indicateur de non-conformité, pas seulement un problème opérationnel.
Lors d’un audit, la présence d’un service critique en état maintenance dans la sortie de svcs -x peut être interprétée comme un manquement. On traite alors le diagnostic avec une démarche d’audit :
- Vérifier que les services liés au logging (
svc:/system/system-log) sont online et pas seulement « enabled » - Contrôler que les services de sécurité réseau (pare-feu, IPsec) n’affichent pas d’état degraded masqué
- Documenter chaque passage en maintenance avec la sortie complète de
svcs -xvet l’horodatage, pour constituer une trace exploitable
Les retours varient sur ce point selon les environnements, mais la tendance est claire : l’erreur SMF devient une pièce d’audit autant qu’un signal de dépannage.
Utilisation de svcprop pour aller au-delà du message d’erreur
La commande svcs -xv donne le diagnostic de surface. Pour creuser, on passe à svcprop, qui affiche toutes les propriétés d’une instance de service : chemins de configuration, utilisateur d’exécution, méthodes de démarrage et d’arrêt, variables d’environnement.
En pratique, quand un service bascule en maintenance sans raison évidente dans la sortie de svcs -xv, on lance svcprop svc:/nom/du/service et on vérifie trois choses :
- La méthode start (
start/exec) : le chemin du binaire ou du script existe-t-il encore sur le système ? - L’utilisateur d’exécution (
start/user) : le compte a-t-il été supprimé ou verrouillé ? - Les dépendances déclarées (
dependency/) : un service requis a-t-il changé de FMRI après une mise à jour ?
Combiner svcs -xv et svcprop couvre la majorité des diagnostics sans ouvrir un seul fichier de log manuellement.
Remettre un service en ligne après lecture du message d’erreur
Une fois la cause identifiée (fichier manquant restauré, port libéré, dépendance réactivée), on ne redémarre pas le service avec un simple svcadm restart. Un service en maintenance nécessite un svcadm clear pour réinitialiser son état avant de le relancer.
La séquence concrète : corriger la cause, puis exécuter svcadm clear svc:/nom/du/service. SMF tente alors de redémarrer le service automatiquement. Si le problème persiste, le service repasse en maintenance et la sortie de svcs -xv se met à jour avec le nouveau message.
Oublier le clear est l’erreur la plus fréquente chez les administrateurs qui viennent de systèmes Linux avec systemd. Sur SMF, l’état maintenance est verrouillé tant qu’il n’est pas explicitement acquitté.
La lecture structurée des messages d’erreur SMF, en commençant par svcs -xv puis en affinant avec svcprop, transforme un diagnostic qui pouvait prendre une heure en une résolution de quelques minutes. Le réflexe à ancrer : ne jamais redémarrer un service en maintenance sans avoir d’abord lu et compris le message que SMF a pris la peine de générer.
