Un service SMF qui bascule en état maintenance sur Solaris ne se contente pas de signaler un problème : il bloque le redémarrage automatique et peut entraîner en cascade l’indisponibilité de tout service dépendant. Nous observons que la majorité des interruptions prolongées ne viennent pas du défaut initial, mais d’une mauvaise lecture des dépendances ou d’un clear prématuré sans correction de la cause racine.
Audit et compliance SMF : la source d’interruptions que les guides classiques ignorent
Depuis Solaris 11.4, le service svc:/application/security/compliance:default peut déclencher des bascules en maintenance sans rapport direct avec l’applicatif surveillé. Ce service, désactivé par défaut, lance des évaluations de conformité périodiques. Son activation mal maîtrisée (benchmark mal ciblé, chemins de logs manquants, saturation du journal) suffit au placer en maintenance.
Le piège vient de la politique d’audit associée. Solaris propose deux comportements en cas d’échec d’écriture des logs d’audit : une politique « halt-on-failure », qui stoppe la machine pour préserver la preuve, et une politique « continue-with-alerting », qui maintient le service actif. Choisir la première sans mesurer l’impact revient à accepter qu’un incident disque sur la partition d’audit provoque une interruption de service complète.
Nous recommandons de vérifier systématiquement la politique d’audit active avant toute mise en production, et de traiter le service compliance comme un composant critique au même titre qu’un service applicatif.
Lire les erreurs svcs -xv avant de faire un svcadm clear
La commande svcadm clear est le réflexe le plus fréquent face à un service en maintenance. C’est aussi la première cause de rechute. Un clear sans diagnostic ne fait que réarmer le compteur de tentatives : si le défaut persiste, SMF rebasculera le service en maintenance après quelques échecs.
Diagnostic complet avec svcs -xv
La commande svcs -xv affiche l’état détaillé de chaque instance en erreur, y compris le motif de la bascule et les dépendances impactées. Elle doit toujours précéder un clear.
svcs -xv [FMRI]donne le fichier de log associé au service, à consulter aveclessoutailpour identifier l’erreur précise (permission refusée, binaire absent, port déjà occupé).svcs -d [FMRI]liste les dépendances directes : si l’une d’elles est elle-même en maintenance ou offline, corriger le service enfant ne servira à rien tant que le parent n’est pas restauré.svcs -D [FMRI]montre les services dépendants, ce qui permet d’évaluer l’impact réel d’un service en maintenance sur le reste de la pile.
Ce triptyque (-xv, -d, -D) constitue le diagnostic minimal. Passer directement au clear sans ces trois vérifications allonge le temps d’interruption.
Corriger puis réarmer
Une fois la cause identifiée et corrigée (fichier de configuration, permission, dépendance réseau), le svcadm clear [FMRI] réarme le service. Si le service ne revient pas en état online dans les secondes qui suivent, relancer svcs -xv pour détecter un second défaut masqué par le premier.
Dépendances SMF et effet cascade sur les services Solaris
SMF structure les services en graphe de dépendances, pas en séquence linéaire. Un service réseau en maintenance peut empêcher le démarrage de dizaines de services applicatifs sans qu’aucun log applicatif ne signale quoi que ce soit. L’analyse des dépendances est la première étape, pas un complément.
Deux types de dépendances génèrent l’essentiel des blocages en cascade :
- Les dépendances
require_all: le service ne démarre que si toutes les dépendances listées sont online. Un seul composant en maintenance bloque tout. - Les dépendances
optional_all: le service démarre même si une dépendance optionnelle est absente, mais attend qu’elle ait fini sa transition. Un service optionnel bloqué en maintenance peut retarder le démarrage sans jamais le bloquer définitivement, créant un délai d’indisponibilité difficile à diagnostiquer.
Pour cartographier rapidement les chaînes de dépendances, svcs -d et svcs -D combinés permettent de remonter du service impacté jusqu’à la dépendance racine en maintenance. Nous recommandons de scripter cette analyse pour les environnements avec plusieurs dizaines de services personnalisés.
Stratégies de prévention des bascules en maintenance sur Solaris
Attendre qu’un service tombe en maintenance pour réagir, c’est accepter l’interruption. La prévention repose sur trois mécanismes complémentaires : la supervision proactive, la configuration des seuils de redémarrage et la gestion des mises à jour SRU.
Supervision des états SMF
Un monitoring qui interroge uniquement le port applicatif ne détecte pas un service en maintenance avant que l’impact utilisateur ne soit visible. Interroger directement svcs -x via un script de supervision (Nagios, Zabbix ou équivalent) permet de détecter une bascule en maintenance dès qu’elle survient, avant qu’elle ne se propage aux services dépendants.
Seuils de redémarrage et startd
Le démon svc.startd bascule un service en maintenance après un nombre configurable d’échecs de démarrage successifs. Ajuster ce seuil selon la criticité du service évite deux écueils : un seuil trop bas qui déclenche la maintenance sur un incident transitoire (redémarrage réseau bref), et un seuil trop haut qui laisse un service défaillant consommer des ressources.
Vérification post-SRU
Après application d’une SRU (Support Repository Update), certains manifestes de service peuvent être modifiés. Un service parfaitement fonctionnel avant la mise à jour peut basculer en maintenance si un chemin de binaire ou une variable d’environnement a changé. Nous recommandons de lancer svcs -x systématiquement après chaque SRU, et de comparer les manifestes avant/après sur les services critiques.
La réduction durable des interruptions liées à SMF passe par un changement de posture : traiter chaque service en maintenance comme un incident à documenter, pas comme un état à effacer. Un clear sans analyse alimente un cycle de rechutes. Un diagnostic structuré avec svcs -xv, une correction ciblée et une supervision continue transforment SMF en filet de sécurité plutôt qu’en source de pannes récurrentes.
