Chapitre 4 Procédure d`initialisation

Durant la procédure d'initialisation de Solaris, 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, dans Initialisation sans Solaris Resource Manager.

• 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é par le lancement de la commande init dans la classe d'ordonnancement de l'UC de Solaris Resource Manager (SHR), plutôt que dans la classe d'ordonnancement par défaut. Le module SHR est chargé et le processus 1 (le processus init) est ordonnancé par Solaris Resource Manager. (Voirinit(1M).)

• Initialement, le processus init et tous ses enfants sont reliés au noeud limite root 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). Tôt dans cette procédure, le script /etc/init.d/init.srm est exécuté. Les actions effectuées par ce script sont décrites à la rubrique Evé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'initialiser 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 (ask) de la commande boot 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. En réponse à cette invite, tapez 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"

Evénements de la séquence d'initialisation

La séquence des événements après le 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.

   A ce moment, la base de données des limites est ouverte, et l'ordonnanceur de Solaris Resource Manager est activé. Consultez la rubrique Activation de Solaris Resource Manager à l'aide de la commande srmadm pour obtenir des informations sur cette procédure.

2. Attribuez les noeuds limites "lost" (srmlost) et "idle" (srmidle).

3. Lancez le démon de Solaris Resource Manager.

   Consultez la rubrique Lancement du démon Solaris Resource Manager pour obtenir des informations 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 root est particulièrement importante. Les processus reliés au noeud limite root 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 root tout processus pouvant faire une utilisation intensive 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. Etant donné que le processus init est relié au noeud limite root, 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 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 root. Cela est souvent indésirable, car tout processus relié au noeud limite root faisant une utilisation intensive 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, afin de l'appeler. Cela n'a aucun effet sur leur UID réel ou effectif.

En voici un exemple :

/usr/srm/bin/srmuser réseau in.named 

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 réseau devraient préalablement être définis.

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

La commande srmadm 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 afin de s'assurer que les valeurs de tous les paramètres seront appropriées lors de l'initialisation 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 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 lancées dans le script init.d 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 root délégué. Le noeud limite root 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'utilisation du noeud limite root délégué sont ajoutées à leurs homologues dans le noeud limite root réel. Cependant, avec cette méthode, les diminutions nettes d'utilisation ne sont pas prises en compte. Ainsi, les modifications d'utilisation 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'utilisation.

• Activation de l'ordonnanceur SHR. 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 rubrique Paramètres globaux de Solaris Resource Manager - commande srmadm décrit certains appels courants de la commande srmadm.

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 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 (3C) 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 utilisations de temps de connexion. La décroissance d'utilisation 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 rubrique Utilisation de la commande limdaemon pour obtenir de plus amples informations sur les options de ligne de commande permettant de contrôler le comportement de limdaemon.