Un service Solaris bloqué en état maintenance ne produit pas toujours un message d’erreur explicite. La commande svcs signale le problème, mais identifier la cause racine demande de croiser plusieurs outils : logs SMF, dépendances, propriétés de configuration. Cet article détaille une méthode de diagnostic structurée pour les services SMF sur Solaris, en intégrant les enjeux de conformité apparus avec Solaris 11.4.
SMF et conformité sur Solaris 11.4 : un service en maintenance devient un écart de sécurité
Sur les versions antérieures de Solaris, un service en état maintenance relevait de l’exploitation pure. L’administrateur corrigeait le problème, relançait le service, et passait à autre chose.
Solaris 11.4 change la donne. Un service de journalisation système ou de sécurité réseau (pare-feu, IPsec) laissé en état maintenance ou disabled est désormais considéré comme un cas de non-conformité, pas seulement comme un incident technique. Le framework de conformité natif de Solaris 11.4 s’appuie directement sur l’état des services SMF pour évaluer la posture de sécurité du système.
Une instance SMF dédiée orchestre ce mécanisme : svc:/application/security/compliance:default, livrée offline par défaut. Sa configuration passe par svccfg pour les propriétés scheduled/interval, scheduled/day et scheduled/hour. Si cette instance tombe elle-même en maintenance, les exécutions planifiées de conformité cessent silencieusement.
Ce double risque (service métier en panne + perte de visibilité conformité) justifie une surveillance renforcée avec svcs -xv combinée à svccfg listprop scheduled pour vérifier que les exécutions produisent bien des résultats récents.
Commandes svcs pour le diagnostic SMF : tableau comparatif
La commande svcs accepte plusieurs options dont l’utilité varie selon le stade du diagnostic. Le tableau ci-dessous classe les combinaisons les plus utiles par ordre de priorité lors d’un dépannage.
| Commande | Ce qu’elle affiche | Quand l’utiliser |
|---|---|---|
svcs -xv |
Services en erreur avec motif, impact sur les dépendants, lien vers la documentation | Premier réflexe face à un service en maintenance |
svcs -lp FMRI |
État détaillé, PID, contrat, manifestes, dépendances avec leur état | Après svcs -xv, pour inspecter un service précis |
svcs -d FMRI |
Liste des services dont dépend l’instance | Quand le motif pointe vers une dépendance non satisfaite |
svcs -D FMRI |
Liste des services qui dépendent de l’instance | Pour mesurer l’impact avant intervention |
svcs -a |
Tous les services, y compris disabled | Inventaire global ou recherche d’un FMRI |
La distinction entre -d (dépendances amont) et -D (dépendants aval) est la source d’erreur la plus fréquente. Confondre les deux revient à chercher la cause dans les conséquences.
Lecture du log SMF : localiser la cause racine d’un état maintenance
svcs -xv indique le chemin du fichier log du service, généralement sous /var/svc/log/. Ce fichier contient les sorties standard et erreur du script de démarrage, horodatées.
Trois catégories de causes dominent dans les logs SMF :
- Erreur de configuration du service : fichier de configuration absent, syntaxe invalide, permission incorrecte sur un fichier référencé par le manifeste. Le log affiche typiquement un message du script start avec un code retour non nul.
- Dépendance non satisfaite : le service requis (require_all ou require_any) est lui-même offline, disabled ou en maintenance. La commande
svcs -d FMRIidentifie immédiatement le service bloquant. - Épuisement du restarter : après plusieurs échecs consécutifs de démarrage, le restarter place le service en maintenance pour éviter une boucle. Corriger la cause sous-jacente ne suffit pas, il faut aussi réinitialiser l’état avec svcadm clear.
Un piège courant : corriger le fichier de configuration puis relancer svcadm enable sans passer par svcadm clear. Le service reste en maintenance parce que le restarter n’a pas reçu le signal de réinitialisation.
Procédure svcadm clear et réactivation d’un service SMF
La séquence de remise en service après correction suit un ordre précis. Inverser les étapes ou en sauter une provoque un retour en maintenance.
- Identifier la cause avec
svcs -xvpuis lecture du log sous/var/svc/log/ - Corriger le problème (fichier de configuration, dépendance, permission)
- Exécuter
svcadm clear FMRIpour réinitialiser l’état maintenance - Vérifier avec
svcs -xvque le service passe en online - Si le service retombe en maintenance, relire le log : la cause initiale n’a pas été entièrement corrigée, ou une seconde erreur apparaît
Pour les services gérés par le restarter inetd (services réseau démarrés à la demande), la procédure reste identique. En revanche, le log peut se trouver dans le fichier log du restarter inetd lui-même plutôt que dans celui du service.
Cas du référentiel SMF corrompu
Si la base de données du référentiel SMF est corrompue, aucun service ne démarre correctement. Le symptôme typique est un échec massif au boot. La procédure consiste à remplacer le référentiel par sa copie de sauvegarde, stockée automatiquement par le système. Cette opération nécessite un démarrage en mode single-user, sans services SMF actifs.
Surveillance proactive des services SMF : au-delà du dépannage réactif
Le dépannage ponctuel ne couvre qu’une partie du problème. Sur Solaris 11.4, la disparition silencieuse d’une exécution planifiée de conformité passe inaperçue si personne ne vérifie régulièrement l’état de svc:/application/security/compliance:default.
Deux vérifications périodiques réduisent le risque :
- Exécuter
svcs -xvde façon planifiée (cron ou équivalent) et alerter dès qu’un service critique apparaît en maintenance ou degraded - Contrôler avec
svccfg listprop scheduledque l’instance de conformité produit des résultats dans l’intervalle attendu - Surveiller la durée des exécutions de conformité : une exécution qui dépasse sa durée habituelle peut signaler un problème sous-jacent sur le système de fichiers ou les dépendances réseau
Cette approche transforme la gestion SMF d’un outil de dépannage réactif en composante active de la posture de sécurité du système. Un service en maintenance n’est plus un simple ticket d’incident : c’est un écart de conformité mesurable, traçable, et auditable.
