Sur Solaris, la commande svcs interroge le framework SMF (Service Management Facility) pour afficher l’état de chaque service. Quand un service passe en état maintenance, il signale un échec que le système ne peut pas résoudre seul. Les causes et les méthodes de diagnostic diffèrent sensiblement entre Solaris 10 et Solaris 11, et confondre les deux environnements mène à des erreurs de procédure coûteuses en temps.
SMF sur Solaris 10 : un framework stable mais rigide
Solaris 10 a introduit SMF en remplacement des scripts init.d hérités de System V. Chaque service est identifié par un FMRI (Fault Management Resource Identifier) de la forme svc:/catégorie/nom:instance. La commande svcs -a liste tous les services, et svcs -x affiche ceux qui sont en erreur avec un diagnostic sommaire.
Pour manipuler un service, on utilise svcadm enable, svcadm disable, svcadm restart ou svcadm refresh (rechargement de la configuration sans redémarrage). Quand un service bascule en maintenance, la procédure standard consiste à consulter le log du service, corriger le problème, puis exécuter svcadm clear pour réarmer le service.
Le système de fichiers racine par défaut sur Solaris 10 est UFS (ou Solaris Volume Manager). Cette particularité a un impact direct sur la maintenance : certains services dépendent de points de montage UFS, et une corruption du système de fichiers peut provoquer des cascades de services en maintenance au démarrage.
Dépendances et ordre de démarrage
Sur Solaris 10, les dépendances entre services sont déclarées dans des manifestes XML situés dans /var/svc/manifest. La commande svcs -d affiche les dépendances d’un service donné, tandis que svcs -D montre les services qui en dépendent.
Un piège fréquent : un service réseau en maintenance bloque silencieusement le démarrage de services applicatifs situés plus haut dans la chaîne. Sur Solaris 10, l’arbre de dépendances est souvent plus profond que sur Solaris 11 parce que certains services hérités (CDE, legacy run levels) restent présents même quand ils ne sont pas utilisés.
svcs maintenance sur Solaris 11 : ce qui change concrètement
Solaris 11 conserve SMF mais modifie plusieurs comportements par défaut. Le système de fichiers racine est ZFS, ce qui élimine toute une catégorie de pannes liées à UFS. Les manifestes de services sont désormais livrés sous forme de paquets IPS (Image Packaging System), et non plus déposés manuellement dans /var/svc/manifest.
La commande svcs -x produit des messages de diagnostic plus détaillés sur Solaris 11. Elle indique non seulement le service en erreur, mais aussi la raison probable et le fichier log à consulter. Sur Solaris 10, le diagnostic exigeait souvent d’aller chercher manuellement dans /var/svc/log/.
Gestion des profils de services
Solaris 11 introduit les profils de services (service profiles), qui permettent de regrouper l’activation ou la désactivation de plusieurs services en une seule opération. Un profil système définit quels services sont actifs selon le rôle de la machine (serveur minimal, serveur complet, poste de travail).
Cette mécanique n’existe pas sur Solaris 10. En pratique, cela signifie qu’après une mise à jour sur Solaris 11, un profil peut réactiver un service précédemment désactivé, ce qui le fait basculer en maintenance si sa configuration n’est plus valide. Ce comportement surprend les administrateurs habitués à Solaris 10 où un service désactivé reste désactivé sauf intervention manuelle explicite.
Pièges fréquents lors du diagnostic svcs maintenance
Trois situations provoquent la majorité des confusions entre Solaris 10 et 11.
- Appliquer
svcadm clearen boucle sans lire le log du service. Sur les deux versions, cette commande réarme le service, mais si la cause racine persiste, il rebascule immédiatement en maintenance. Le log se trouve dans/var/svc/log/sur Solaris 10 et au même emplacement sur Solaris 11, mais Solaris 11 journalise aussi viasvcs -Lqui donne directement le chemin du fichier. - Confondre
svcadm restartetsvcadm refresh. Le premier tue et relance le processus. Le second relit le manifeste ou le fichier de configuration sans interrompre le service. Sur Solaris 11,refreshest particulièrement utile après modification de propriétés viasvccfg, car les propriétés SMF sont stockées dans un dépôt transactionnel, pas dans de simples fichiers texte. - Ignorer les dépendances réseau sur Solaris 11. Le service
svc:/network/physical:defaultest remplacé parsvc:/network/physical:nwam(Network Auto-Magic) sur certaines configurations Solaris 11. Un service qui dépend explicitement de l’ancien FMRI ne trouvera pas sa dépendance et restera en maintenance.
L’impact du cycle de support sur la maintenance des services
Solaris 10 est désormais uniquement en phase de support étendu. Les correctifs de sécurité (CPU, Critical Patch Updates) continuent d’être publiés, mais à un rythme réduit. Solaris 11.4, en revanche, reçoit des SRU (Support Repository Updates) et des CPU trimestriels réguliers.
Cette différence de rythme a une conséquence directe : sur Solaris 11.4, les services qui basculent en maintenance après un SRU sont souvent liés à des modifications de manifestes introduites par le correctif. Sur Solaris 10, les passages en maintenance sont plus souvent liés à des problèmes matériels ou à des configurations figées depuis des années.
Commandes svcs à connaître sur les deux versions
Le tableau suivant récapitule les commandes de diagnostic les plus utiles et leur comportement selon la version.
| Commande | Solaris 10 | Solaris 11 |
|---|---|---|
svcs -x |
Liste les services en erreur avec un message court | Diagnostic étendu avec raison probable et chemin du log |
svcs -L [FMRI] |
Non disponible | Affiche le chemin complet du fichier log du service |
svcs -p [FMRI] |
Liste les processus associés au service | Identique, fonctionne aussi avec les zones |
svcs -d / -D |
Dépendances directes et dépendants | Identique, mais l’arbre peut différer (NWAM, profils) |
svcadm clear |
Réarme le service après correction | Identique, mais vérifier les profils actifs avant |
Sur Solaris 11, la commande svcs -L fait gagner un temps considérable en évitant de parcourir manuellement l’arborescence des logs. C’est souvent le premier réflexe à adopter face à un service en maintenance.
La distinction entre les deux versions se résume à un changement de philosophie : Solaris 10 expose un SMF qu’on pilote manuellement, service par service. Solaris 11 ajoute des couches d’automatisation (profils, IPS, NWAM) qui simplifient l’exploitation courante mais introduisent des comportements implicites. Quand un service passe en maintenance sur Solaris 11, la cause se trouve aussi souvent dans ces couches intermédiaires que dans le service lui-même.
