Un service qui bascule en état maintenance sous Solaris ne redémarrera pas tout seul. SMF (Service Management Facility) verrouille volontairement l’instance fautive pour éviter qu’un redémarrage en boucle ne provoque des dégâts collatéraux sur l’infrastructure. Comprendre ce mécanisme et savoir le débloquer rapidement fait partie du quotidien de l’administration Solaris.
Mécanisme SMF et transition vers le statut maintenance
SMF surveille chaque service via le restarter master (svc:/system/svc/restarter:default). Lorsqu’un service échoue à démarrer plusieurs fois consécutives, le restarter modifie son état de offline à maintenance. Ce basculement est définitif tant qu’un administrateur n’intervient pas.
La logique est stricte : un service en maintenance ne sera plus relancé automatiquement. Même si la cause du blocage disparaît (fichier corrigé, dépendance revenue en ligne), SMF considère que l’intervention humaine reste nécessaire. Nous observons régulièrement ce comportement après l’application d’un Critical Patch Update, lorsque la configuration d’un service n’est plus compatible avec une bibliothèque mise à jour.
Sur Solaris 11.4, le cycle de patching reste actif avec des SRU réguliers. Un service passé en maintenance juste après un patch doit être analysé dans ce contexte précis, pas uniquement comme une erreur de configuration isolée.
Diagnostiquer un service en maintenance avec svcs
La commande svcs -x liste tous les services en état anormal et affiche un résumé du problème détecté. Pour obtenir le détail complet, nous recommandons systématiquement la forme verbeuse.
svcs -xv nom_du_service renvoie le FMRI complet, l’horodatage du passage en maintenance, la raison du blocage et le chemin vers le fichier de log correspondant. C’est ce fichier de log qui contient la trace exploitable.
svcs -aaffiche l’ensemble des services, y compris ceux en état disabled ou legacy_run, pour avoir une vue globale de l’infrastructure SMFsvcs -p nom_du_servicemontre les processus associés au service, ce qui permet de vérifier si un processus orphelin bloque le redémarragesvcs -d nom_du_serviceliste les dépendances du service, pour identifier si le blocage vient d’un service parent lui-même en erreursvcs -D nom_du_serviceaffiche les services dépendants, utile pour évaluer l’impact en cascade d’un service bloqué
La colonne STATE dans la sortie de svcs indique maintenance en clair. La colonne STIME donne l’heure exacte du basculement, ce qui permet de corréler avec un événement réseau, un déploiement ou un patch récent.
Procédure svcadm clear : sortir du statut maintenance Solaris
Une fois la cause identifiée et corrigée, la commande svcadm clear nom_du_service réinitialise l’état du service. SMF le fait repasser en offline puis tente un démarrage normal. Si la correction est effective, le service passe en online.
Exécuter svcadm clear sans avoir corrigé la cause renvoie le service en maintenance en quelques secondes. C’est un piège classique : l’administrateur pressé lance le clear, le service retombe, et le compteur de tentatives repart. La méthode fiable suit un enchaînement précis.
Séquence de résolution recommandée
Commencer par lire le log indiqué par svcs -xv. Sur Solaris 11.4, ces logs se trouvent généralement sous /var/svc/log/. Chercher les lignes d’erreur les plus récentes, qui correspondent au dernier échec de démarrage.
Corriger le problème identifié (fichier de configuration invalide, permission manquante, port déjà occupé, dépendance absente). Puis exécuter svcadm clear FMRI en utilisant le FMRI complet plutôt que le nom court, pour éviter toute ambiguïté si plusieurs instances existent.
Vérifier immédiatement avec svcs -xv que le service est bien passé en online. Si le statut repasse en maintenance, le log contiendra une nouvelle erreur, potentiellement différente de la première.
Dépendances et maintenance en cascade sur l’infrastructure
Un service en maintenance peut bloquer d’autres services qui en dépendent. SMF gère les dépendances de manière déclarative : si un service requiert une dépendance de type require_all et que cette dépendance est en maintenance, le service dépendant reste en état offline sans tenter de démarrer.
Nous rencontrons fréquemment cette situation avec les services réseau. Un service de configuration réseau bloqué empêche le démarrage de tous les services applicatifs qui déclarent une dépendance réseau. Le résultat ressemble à une panne massive alors que la cause se limite à un seul service racine.
La commande svcs -d permet de remonter la chaîne. En pratique, commencer par identifier tous les services en maintenance avec svcs -x, puis traiter d’abord celui qui se trouve le plus bas dans l’arbre de dépendances.
Cas particulier des services RAD et administration distante
Sur Solaris 11.4, des vulnérabilités touchant le composant RAD (Remote Administration Daemon) ont été corrigées dans des patchs récents, dont une faille d’authentification bypass. Un service RAD en maintenance après un patch de sécurité peut signaler une incompatibilité entre la configuration locale et les nouvelles exigences de sécurité du composant.
Dans ce cas, vérifier que les certificats et les configurations d’authentification de RAD sont à jour avant d’exécuter le clear. Un clear sur un service d’administration distante vulnérable expose le système si le patch n’a pas été correctement appliqué.
Monitoring et prévention des passages en maintenance
Attendre qu’un administrateur découvre manuellement un service en maintenance n’est pas viable sur une infrastructure de production. La sortie de svcs -x se scripte facilement pour alimenter un outil de monitoring et déclencher des alertes sur tout changement d’état.
Un script cron ou un check Nagios/NRPE qui exécute svcs -x à intervalle régulier et parse la sortie détecte un passage en maintenance en quelques minutes. L’alerte doit inclure le FMRI et le chemin du log pour que l’administrateur puisse intervenir sans étape de diagnostic supplémentaire.
La prévention passe aussi par la validation de configuration avant tout redémarrage de service. Certains services (comme Nagios Core sous Solaris) vérifient leur configuration au démarrage et basculent en maintenance si elle est invalide. Tester la configuration avec les outils natifs du service avant de lancer svcadm restart évite le passage en maintenance inutile.
Le statut maintenance de SMF reste un mécanisme de protection, pas une anomalie. Sur un système Solaris correctement supervisé, chaque passage en maintenance génère une alerte, déclenche une analyse du log, et se résout par une correction ciblée suivie d’un svcadm clear. Traiter ce statut comme un simple obstacle à contourner, c’est ignorer le signal que SMF envoie sur l’état réel du service.
