Chapitre 4 Procédure d'initialisation

Durant la procédure d'initialisation d'UNIX, diverses facettes de Solaris Resource Manager sont activées à divers moments. Voici les étapes principales :

• Lors du démarrage du noyau, divers paramètres sont chargés depuis le fichier /etc/system. Certains d'entre eux influencent Solaris Resource Manager. Ils sont détaillés ci-après.

• Lorsque le noyau poursuit son initialisation, après la création du processus 0 mais avant celle du processus 1, Solaris Resource Manager est initialisé. Cela inclut le chargement du module SHR et l'ordonnancement du processus 1 (le processus init(1M)) par Solaris Resource Manager. Cela est effectué en lançant init(1M) dans la classe d'ordonnancement SHR, plutôt que dans la classe d'ordonnancement par défaut.

• Initialement, le processus init(1M) et tous ses enfants sont reliés au noeud limite racine délégué.

• Lorsque le noyau est complètement initialisé, le système passe du mode mono-utilisateur à l'un des modes multi-utilisateur (généralement le niveau d'exécution 2 ou 3). Au début de cette procédure, le script /etc/init.d/init.srm est exécuté. Les actions effectuées par ce script sont décrites à la section "Événements de la séquence d'initialisation" et mettent en oeuvre les opérations normales de Solaris Resource Manager.

Initialisation sans Solaris Resource Manager

S'il est nécessaire d'amorcer le système sans activer Solaris Resource Manager, il suffit de modifier la variable initclass dans le fichier /etc/system afin de la régler au partage de temps (TS) plutôt qu'à SHR. Pour ce faire, vous pouvez utiliser l'option -a de la commande boot(1M), et vous serez invité à spécifier un fichier système. Aux autres invites, appuyez simplement sur la touche Entrée afin d'accepter les valeurs par défaut, jusqu'à l'invite vous demandant le nom du fichier système. Tapez alors etc/system.noshrload (sans barre oblique initiale). Voici un exemple de cette procédure :

ok boot -a 
Booting from: sd(0,0,0) -a
Enter filename [kernel/unix]: 
Enter default directory for modules
 [/platform/SUNW,UltraSPARC/kernel /kernel /usr/kernel]: 
SunOS Release 5.6 Version ... [UNIX(R) System V Release 4.0] 
Copyright (c) 1983-1997, Sun Microsystems, Inc. 
Name of system file [etc/system]: etc/system.noshrload
root filesystem type [ufs]: 
Enter physical name of root device
 [/sbus@1,f8000000/esp@0,800000/sd@3,0:a]:

Il faut noter que /etc/system.noshrload est simplement une copie de sauvegarde de /etc/system effectuée lors de l'installation de Solaris Resource Manager. Si vous avez ultérieurement modifié /etc/system, le fichier /etc/system.noshrload doit être maintenu en parallèle de manière à ce qu'il ne diffère que par l'occurrence de la modification de Solaris Resource Manager :

# diff /etc/system /etc/system.noshrload 
< # enable srm 
< set initclass="SHR"

Événements de la séquence d'initialisation

La séquence des événements après l'initialisation du système lors du passage au mode multi-utilisateur est particulièrement importante dans Solaris Resource Manager. Les étapes ci-dessous présentent une séquence établissant correctement le système Solaris Resource Manager :

1. Configurez et activez Solaris Resource Manager au moyen de la commande srmadm(1MSRM). À ce moment, la base de données des limites est ouverte, et l'ordonnanceur de Solaris Resource Manager est activé. Consultez la section "Activation de Solaris Resource Manager à l'aide de la commande srmadm" pour des renseignements sur l'utilisation de la commande srmadm(1MSRM) afin d'activer Solaris Resource Manager.

2. Attribuez les noeuds limites "lost" et "idle".

3. Lancez le démon de Solaris Resource Manager. Consultez la section "Lancement du démon Solaris Resource Manager" pour obtenir des renseignements sur cette procédure.

4. Lancez les autres démons du système sur un noeud limite approprié.

Le script utilisé par défaut dans les étapes 1 à 3 de la procédure ci-dessus est présenté à l'annexe.

Processus démons du système

La liaison de démons (processus de maintenance du système normalement exécutés en permanence) à un noeud limite autre que le noeud limite racine est particulièrement importante. Les processus reliés au noeud limite racine ont un ordonnancement spécial et obtiennent toujours toutes les ressources de l'UC qu'ils demandent; il est donc déconseillé d'associer au noeud limite racine tout processus pouvant de faire un usage intensif de l'UC. En liant les démons à leur propre noeud limite, l'administrateur central peut leur attribuer une part appropriée de l'UC.

Au cours de la procédure d'initialisation, chaque nouveau processus hérite sa liaison au noeud limite de son processus père. Étant donné que le processus init(1M) est relié au noeud limite racine, tous les processus subséquents le sont aussi. Lorsque le script d'initialisation de Solaris Resource Manager est exécuté et que la base de données des noeuds limites est ouverte, les processus peuvent alors être reliés à d'autres noeuds limites, mais seulement lorsqu'un processus effectue un appel système setuid(2) explicite (comme le fait login(1)) ou demande explicitement à Solaris Resource Manager de se lier à un noeud limite particulier, comme le fait la commande srmuser(1SRM). L'exécution d'un programme avec le bit de mode du fichier setuid activé n'entraîne pas de changement de liaison au noeud limite.

Ainsi, tous les programmes système lancés automatiquement lors du démarrage du système seront reliés au noeud limite racine. Cela est souvent indésirable, car tout processus relié au noeud limite racine faisant un usage intensif de l'UC perturbera fortement l'exécution des autres processus. Il est donc recommandé de lier explicitement tout processus démon lancé lors de la procédure d'initialisation à son propre noeud limite au moyen de la commande srmuser(1SRM). Cela n'a aucun effet sur leur UID réelle ou effective.

En voici un exemple :

# /usr/srm/bin/srmuser Start in.named attached to the my_daemons lnode.  

Ces lignes pourraient remplacer l'appel existant du démon named(1M) dans son script de démarrage. Pour ce faire, un compte utilisateur et un noeud limite pour "network" devraient préalablement être définis.

Activation de Solaris Resource Manager à l'aide de la commande srmadm

La commande srmadm(1MSRM) permet à l'administrateur de contrôler le mode d'exploitation et la configuration globale du système Solaris Resource Manager. Cette commande est généralement employée lors de la transition au niveau d'exécution 2 ou 3 dans le script init.d(4) /etc/init.d/init.srm de Solaris Resource Manager afin de s'assurer que les valeurs de tous les paramètres seront appropriées lors du démarrage du système, et que le système Solaris Resource Manager sera activé avant que les utilisateurs ne puissent accéder au système. La commande srmadm(1MSRM) permet également d'administrer les paramètres globaux de Solaris Resource Manager. Consultez la page de manuel srmadm(1MSRM) pour connaître les paramètres réglables au moyen de la commande srmadm. Les commandes srmadm(1MSRM) lancées dans le script init.d(4) de Solaris Resource effectuent les actions suivantes :

• Ouverture de la base de données des limites. Jusqu'à ce moment, tout processus lancé est automatiquement relié à un noeud limite racine délégué. Le noeud limite racine délégué vous permet de vous assurer qu'un noeud limite est toujours disponible pour la liaison de processus, quel que soit l'état d'exploitation de Solaris Resource Manager. Pour cette raison, il est important que la base de données des limites soit ouverte avant le démarrage des processus non-racine. Lors de l'ouverture de la base de données des limites, les valeurs des attributs d'usage du noeud limite racine délégué sont ajoutées à leurs homologues dans le noeud limite racine. Cependant, avec cette méthode, les diminutions nettes d'usage ne sont pas prises en compte. Ainsi, les modifications d'usage antérieures à l'ouverture de la base de données des limites ne sont pas annulées.

• Application des limites.

• Définition des paramètres contrôlant le comportement de l'ordonnanceur SHR de Solaris Resource Manager, par exemple le taux de décroissance de l'usage.

• Activation de l'ordonnanceur de Solaris Resource Manager. Antérieurement, les processus appartenant à la classe d'ordonnancement SHR étaient programmés en mode de recherche circulaire simple, et les attributions de ressources de l'UC définies dans le système Solaris Resource Manager n'avaient aucun effet.

La section "Paramètres globaux de Solaris Resource Manager - commande srmadm" décrit certains appels courants de la commande srmadm(1MSRM).

Lancement du démon Solaris Resource Manager

Le programme limdaemon(1MSRM) est le démon du mode utilisateur de Solaris Resource Manager. Il est normalement appelé lors de la transition au niveau d'exécution 2 ou 3 en tant que dernière étape du script init.d(4) de Solaris Resource Manager. Il ne faut pas le confondre avec le processus système srmgr (dans la classe SYS), lancé par le noyau. Le listage ps(1) suivant illustre ces deux processus :

# ps -efc | egrep 'limdaemon|srmgr' 
root   4   0 SYS 60 18:42:14 ?        0:05 srmgr  
root  92   1 SHR 19 18:42:32 ?        0:41 limdaemon
 

Le programme limdaemon remplit les fonctions suivantes :

• il reçoit les messages de notification et les transmet aux terminaux des utilisateurs destinataires ;

• il reçoit les messages de notification de connexion ou de déconnexion, et conserve un registre précis de toutes les sessions de Solaris Resource Manager en cours ;

• il met périodiquement à jour les temps de connexion de tous les utilisateurs actuellement en session sous Solaris Resource Manager (facultatif) ;

• il détecte les utilisateurs ayant atteint leur limite de temps de connexion, détruit le processus, et ferme leur session (facultatif) après un intervalle de grâce ;

• il consigne toutes les actions au moyen de syslog(3) dans syslogd(1M).

Lorsqu'il est avisé des ouvertures de session de Solaris Resource Manager, limdaemon surveille le temps de connexion au terminal de tous les utilisateurs et le compare à leur limite de temps de connexion. Lorsque leur limite de temps de connexion est presque atteinte, ils reçoivent un message d'avertissement. Lorsque le temps est expiré , une période de grâce supplémentaire leur est accordée avant l'arrêt de tous leurs processus et la fermeture de leur session.

Le programme limdaemon diminue progressivement les usages de temps de connexion. La décroissance d'usage pour la catégorie de périphériques terminaux doit être effectuée si des limites de temps de connexion sont employées. Consultez la section "Options de la commande limdaemon" pour obtenir des détails sur les options de ligne de commande permettant de contrôler le comportement de limdaemon.