Services - Solaris

Solaris 8 et 9

Les services sous Solaris 8 et 9 sont des services classiques de type System V. C'est-à-dire qu’ils sont dans /etc/init.d/ et sont appelés depuis /etc/rc<niveau-de-runlevel>.d/.

Attention, petite particularité : les scripts dans /etc/rc<niveau-de-runlevel>.d/ ne sont pas des liens symboliques vers /etc/init.d/, mais des liens physiques.

Solaris 10

Principe

Sous Solaris 10, les services ont été entièrement revus. On fonctionne toujours en système V, avec des runlevels, mais le fonctionnement a été entièrement revu. Cependant, l’ancienne syntaxe reste possible à utiliser, pour garder la compatibilité. Le principal avantage de la nouvelle méthode est que les services ne sont plus lancés les uns après les autres, mais tous en parallèle, ce qui est beaucoup plus rapide sur les processeurs multithread actuels. Pour que l’ensemble reste cohérant, il a été ajouté une notion de dépendance entre les services : ils démarrent tous en même temps, mais certains ne poursuivront leur démarrage que si tel ou tel autre a fini de démarrer. Par exemple, ssh ne finira de se lancer que quand le réseau sera prêt.

Pour simplifier les dépendances (un service peut dépendre de beaucoup d'autres), il existe des milestones qui correspondent aux grandes étapes du démarrage (par exemple : single-user, network, multi-user). Pour voir tous les milestones existants, taper svcs –a|grep milestone. Les milestones se comportent comme des services normaux (mêmes commandes).

Les commandes

• Informations : svcs
• Administration : svcadm
• Configuration : svccfg
• Détails : svcprop

Exemples :

Afficher l’état de tous les services :

# svcs -a
STATE          STIME    FMRI
legacy_run     Jul_01   lrc:/etc/rc2_d/S10lu
legacy_run     Jul_01   lrc:/etc/rc2_d/S20sysetup
legacy_run     Jul_01   lrc:/etc/rc2_d/S40llc2
legacy_run     Jul_01   lrc:/etc/rc2_d/S42ncakmod
legacy_run     Jul_01   lrc:/etc/rc2_d/S47pppd
[…]

Afficher l’état d’un service en particulier (on peut mettre juste "ssh" ou "svc:/network/ssh:default" ou un morceau de tout ça :

# svcs ssh
STATE          STIME    FMRI
online         juil_01  svc:/network/ssh:default

Activer / désactiver / relancer / relire le fichier de conf :

svcadm enable ssh
svcadm disable ssh
svcadm restart ssh
svcadm refresh ssh

(restart et refresh ne marchent pas avec tous les services)

Voir les services qui dépendent d'un service :

svcs –D ssh

Voir les services dont dépend un service :

svcs –d ssh

Les fichiers de configuration

• XML : /var/svc/manifest/
• Logs : /var/svc/log/
• Config : /etc/svc/
• Scripts : /lib/svc/manifest/

Dépannage

On peut tuer un service avec une la commande suivante :

pkill -9 cron
svcs –p cron

Un service qui est tué se relance tout seul, mais au bout de plusieurs relances infructueuses, le service passe en mode maintenance. On peut s'amuser à forcer un service à passer en mode maintenance en faisant une boucle qui le tue plusieurs fois de suite.

Pour avoir plus d'informations sur la raison du plantage, on utilise "svcs –xv <service>" qui donne le chemin vers les logs.

Exemple de plantage volontaire + relance du service ssh (à ne pas faire si on est connecté en ssh !) :

# svcs ssh
STATE          STIME    FMRI
online         14:43:35 svc:/network/ssh:default
# while true; do pkill -9 ssh; done
^C
# svcs ssh
STATE          STIME    FMRI
maintenance    14:44:00 svc:/network/ssh:default
# 
# 
# svcs -xv ssh
svc:/network/ssh:default (SSH server)
 State: maintenance since Fri Nov 05 14:44:00 2010
Reason: Restarting too quickly.
 See: http://sun.com/msg/SMF-8000-L5
 See: man -M /usr/share/man -s 1M sshd
 See: /var/svc/log/network-ssh:default.log
Impact: This service is not running.
# 
# 
# svcadm disable ssh
# svcadm enable ssh
# 
# svcs ssh
STATE          STIME    FMRI
online         14:44:40 svc:/network/ssh:default
#

Création d'un nouveau service

Écrire un script

# vi /lib/svc/method/mon_script

==> 

#!/bin/sh
case $1 in
start)
touch /var/tmp/start`date`
;;
stop)
touch /var/tmp/stop`date`
;;
esac
exit

Écrire un manifest XML

# cd /var/svc/manifest
# cp system/coreadm.xml site/mon_script.xml
# vi site/mon_script.xml

Adapter les lignes suivantes (sans toucher au reste) :

<service_bundle … name="PACK:mon_script">
 <service name="site/mon_script">        => va créer svc:/site/mon_script:default
 <dependency value='svc:/milestone/multi-user-server:default'>
 <exec_method
 start exec="/lib/svc/method/mon_script start"
 stop exec="/lib/svc/method/mon_script stop"
 >

Attention : la syntaxe de la balise "dependency" varie suivant les versions !

Dans les premières versions de Solaris 10, elle ressemble à ceci :

<dependency value='svc:/milestone/multi-user-server:default'>

Dans les versions plus récentes il faut plus d'informations :

<dependency
        name='ma_dependance'
        grouping='require_all'
        restart_on='none'
        type='service'>
        <service_fmri value='svc:/milestone/multi-user-server:default' />
</dependency>

Vérifier la validité du fichier XML

# svccfg –v validate /var/svc/manifest/site/mon_script.xml

Si tout va bien, il n'affiche rien.

S'il ne parvient même pas à effectuer la validation :

# xmllint –valid /var/svc/manifest/site/mon_script.xml

Injecter le manifest dans le repository

# svccfg import /var/svc/manifest/site/mon_script.xml

(pour supprimer c'est "svccfg delete /var/svc/manifest/ site/mon_script.xml")

Utilisation

# svcadm enable mon_script
# svcadm disable mon_script
# svcadm enable mon_script

Si on modifie le script, il faut refaire un "import".

On fait un premier enable pour vérifier que ça démarre bien (attention, ça lance le start du daemon, donc il ne faut pas que le process ait été lancé à la main avant, sinon ça risque de poser problème !).

Ensuite on fait un "disable" pour valider que le stop fonctionne.

Puis on le redémarre si on veut qu'il soit actif.