Boucles de groupe

Lorsqu'un noeud limite est activé, tous ses parents jusqu'au noeud limite racine le sont aussi. Si, ce faisant, l'un des noeuds limites a un père ayant déjà été détecté, cela signifie que le noyau a découvert une boucle de groupe.

Si la base de données des limites est endommagée, une boucle de groupe peut être créée (l'un des ascendants d'un noeud limite est également l'un de ses enfants). Le cas échéant, le noyau relie automatiquement la boucle à l'arbre d'ordonnancement en la brisant de façon arbitraire pour la relier en tant que groupe sous le noeud limite racine. Lorsque cela se produit, le noeud limite auquel la boucle est reliée sur l'arbre d'ordonnancement devient le chef d'un groupe de premier niveau. Il est possible que des membres de ce groupe héritent de privilèges ou de limites supérieurs à ceux auxquels ils auraient normalement droit.

Causes

Les boucles de groupe sont évitées par limadm(1MSRM) lors de la configuration de parents de groupe d'ordonnancement. La seule cause d'une boucle de groupe est une base de données de limites endommagées. Il s'agit d'un problème grave pouvant générer toutes sortes de défaillances sous Solaris Resource Manager du fait que la base de données des limites est essentielle à son fonctionnement.

Effets

Lorsque le noyau détecte une boucle de groupe, il relie silencieusement l'un des noeuds limites de la boucle directement sous le noeud limite racine. La boucle n'ayant ni début ni fin, le noyau ne peut déterminer quel est le noeud limite supérieur.

Correction

Ce problème se corrige de lui-même dans la structure de l'arbre d'ordonnancement puisque le noyau relie le noeud limite au noeud racine. La liaison étant effectuée à un point arbitraire de la boucle, l'administrateur doit déterminer où le noeud limite devrait être relié et vérifier également le point de connexion de tous les autres membres de la boucle.

Le résultat d'une réparation automatique de boucle de groupe peut être affiché en dressant la liste des noeuds limites enfants du noeud racine. La commande :

% limreport 'sgroup==0' - uid lname

affiche la liste de tous les noeuds limites dont le père est le noeud limite racine. Si des noeuds limites de cette liste ne devraient pas être des enfants du noeud limite racine, cela peut indiquer qu'ils sont au premier niveau d'une boucle de groupe ayant été reliée sous le noeud racine.

Pour l'administrateur, la principale préoccupation lorsqu'une boucle de groupe est détectée est que de nombreux problèmes beaucoup plus graves pourraient se manifester du fait que la base de données des limites est endommagée. Si l'administrateur soupçonne une base de données des limites endommagée, il doit en vérifier la validité afin de confirmer le problème et prendre les mesures qui s'imposent. Pour savoir comment détecter et corriger une base de données des limites endommagée, voir "Reprise après une panne".

Reprise après une panne

La défaillance d'un système Solaris est source de nombreuses préoccupations pour l'administrateur, et d'autres facteurs doivent être considérés lorsqu'un système Solaris Resource Manager est utilisé, soit :

• la possibilité que la base de données des limites ait été endommagée par une défaillance de disque ou un autre incident matériel ;

• le fonctionnement de limdaemon(1MSRM) pendant une panne de système, notamment en ce qui concerne la facturation du temps de connexion.

Les sections ci-après traitent de ces sujets en détail et fournissent des suggestions pour corriger la situation.

Base de données des limites endommagée

Les fonctions de maintenance de la base de données des limites de Solaris Resource Manager sont très robustes et les dommages sont peu probables. Cependant, si cela se produit, il s'agit d'un problème important pour l'administrateur, car cette base de données est essentielle au fonctionnement de Solaris Resource Manager. Tout dommage potentiel doit faire l'objet d'une recherche minutieuse et être réparé s'il est confirmé.

Symptômes

Aucun symptôme ne permet de déterminer avec certitude si la base de données des limites a été endommagée, mais certains indices peuvent indiquer une telle situation :

• La détection d'une boucle de groupe par Solaris Resource Manager. Différentes fonctions de Solaris Resource Manager permettent d'éviter les boucles de groupe ; seul un attribut sgroup endommagé peut en être la source. Pour en savoir davantage, voir "Boucles de groupe".

• L'affichage du message "No limits information available" lorsqu'un utilisateur tente d'ouvrir une session et que son compte est rejeté. Cela peut se produire si les dommages à la base de données des limites provoquent la désactivation de l'attribut flag.real, ce qui supprime le noeud limite de l'utilisateur ainsi que tout noeud limite orphelin (pour en savoir davantage, reportez-vous à la section Noeuds limites orphelins). Notez que le message "No limits information available" apparaîtra également si aucun noeud limite n'a été créé pour le compte ou s'il a été supprimé intentionnellement; il ne signifie donc pas nécessairement que la base de données des limites a été endommagée.

• Des valeurs non valides apparaissent soudainement dans les attributs d'usage ou de limites. Cela peut faire en sorte que des utilisateurs atteignent subitement des limites.

• Des utilisateurs signalent des pertes de privilèges ou l'obtention de privilèges inhabituels, ce qui est causé par des indicateurs de privilèges altérés.

Lorsque l'administrateur soupçonne que la base de données des limites a été endommagée, la façon la plus sure de le confirmer consiste à exécuter limreport(1SRM) afin de demander la liste des noeuds limites ayant des attributs dont les valeurs ne se situent pas dans leur plage de valeurs habituelle. Cette commande permet également de dresser la liste des noeuds limites dont l'indicateur flag.real est désactivé, ce qui indique la présence, dans la table des mots de passe, de comptes n'ayant pas de noeud limite.

Solution

Si des dommages sont détectés, l'administrateur doit restaurer une version valide de la base de données des limites. Si les dommages sont limités à une partie restreinte de la base de données, l'administrateur peut parvenir à enregistrer le contenu de tous les autres noeuds limites, puis les restaurer dans une nouvelle base de données des limites à l'aide des commandes limreport(1SRM) et limadm(1MSRM). Si une copie récente de la base de données n'est pas disponible, cela est préférable, puisque la nouvelle base de données contiendrait les attributs d'usage et cumulatifs les plus récents. Pour connaître la procédure de sauvegarde et de restauration de la base de données des limites, consultez la section Gestion des noeuds limites. Pour les cas simples de noeuds limites manquants, il peut être suffisant de simplement les recréer à l'aide la commande limadm.

Perte de temps de connexion par limdaemon

Si limdaemon(1MSRM) est interrompu, tous les utilisateurs en session ne sont plus facturés pour leur temps de connexion. En outre, lorsque limdaemon(1MSRM) est redémarré, les utilisateurs en session continue à utiliser leur terminal gratuitement. Cela s'explique par le fait que le démon utilise les avis d'ouverture de session fournis par login(1) pour établir un relevé de session Solaris Resource Manager depuis les structures internes utilisées pour calculer les frais de temps de connexion. Par conséquent, chaque fois que le démon démarre, aucune session Solaris Resource Manager n'est établie avant la réception du premier avis.

Cela n'est habituellement pas un problème si l'interruption de limdaemon est causée par une panne du système, celle-ci entraînant également l'arrêt des autres processus. Aucune session ne peut donc reprendre avant le redémarrage du système.

Si limdaemon(1MSRM) est arrêté pour une autre raison, l'administrateur a deux choix :

1. Redémarrer le démon immédiatement et ne pas tenir compte des pertes de facturation de temps de terminal des utilisateurs déjà en session, auquel cas un utilisateur pourrait utiliser gratuitement un terminal jusqu'à ce qu'il soit détecté et que sa session soit fermée.

2. Mettre le système en mode mono-utilisateur, puis de nouveau en mode multi-utilisateurs, ce qui met fin à toutes les sessions en cours et empêche les utilisateurs d'ouvrir une session de nouveau avant le redémarrage du démon.