Chapitre 9 Dépannage

Cette section est conçue pour aider les administrateurs à diagnostiquer les problèmes relatif à l'utilisation de Solaris Resource Manager.

Un utilisateur ne peut pas ouvrir une session

• Il n'y a aucun noeud limite correspondant à son UID. Aucun administrateur n'a configuré de noeud limite pour le compte de cet utilisateur. Le problème est signalé par un message indiquant qu'aucune information sur les limites n'est disponible. Reportez-vous à la section "Noeuds limites orphelins".

• L'indicateur nologin ou noattach de l'utilisateur est activé.

• L'indicateur onelogin de l'utilisateur est activé, et celui-ci a déjà une session en cours sur un autre terminal ou une autre fenêtre.

• L'utilisateur a atteint sa limite de temps de connexion. Il doit attendre que l'usage diminue avant de recommencer, ou l'administrateur peut changer l'attribut terminal.usage ou terminal.limit de l'utilisateur pour accroître le temps de connexion.

• Le noeud limite de l'utilisateur est devenu orphelin suite à la suppression de son noeud père. Voir "Noeuds limites orphelins".

Aucune des restrictions de Solaris Resource Manager mentionnées ci-dessus ne s'applique à l'utilisateur racine.

Un utilisateur n'est pas informé lorsqu'il atteint ses limites

Pendant le fonctionnement normal de Solaris Resource Manager, l'utilisateur en session reçoit des messages chaque fois qu'une limite est dépassée. L'utilisateur peut ne pas être au courant du problème et le système semblera fonctionner anormalement, mais l'administrateur système sera informé du problème.

La transmission des messages est effectuée par le programme démon limdaemon de Solaris Resource Manager. Si les messages ne sont pas transmis, l'administrateur peut étudier plusieurs possibilités : - -

• La fenêtre de console est masquée. Si l'utilisateur ouvre une session dans une fenêtre puis ouvre d'autres fenêtres qui masquent la première, il ne verra pas les messages qui y sont affichés.

• Le programme limdaemon(1MSRM) n'est pas en cours d'exécution.

• limdaemon est incapable d'allouer dynamiquement de la mémoire additionnelle pour maintenir ses structures internes. Si cela se produit, limdaemon affiche un message de diagnostic sur la console système dès le premier échec. Il continue ensuite à essayer d'obtenir de la mémoire mais n'affiche plus de messages.

• Le fichier utmp est endommagé ou manquant. limdaemon utilise ce fichier pour déterminer les terminaux où un utilisateur est en session afin d'y envoyer des messages. Si le fichier utmp est endommagé ou manquant, un message d'erreur est signalé à la console et la transmission des messages est interrompue.

• limdaemon est incapable de transmettre un message en raison d'une restriction système. Par exemple, si limdaemon ne peut pas ouvrir une fenêtre sur un terminal afin de transmettre un message, celui-ci est annulé.--

Impossible de changer le groupe d'un utilisateur

L'attribut sgroup indique le père d'un noeud limite dans l'arbre d'ordonnancement. Cette hiérarchie permet de réguler l'usage des ressources et d'ordonnancer l'UC. Pour cette raison, la modification de l'attribut sgroup fait l'objet de plusieurs mesures de sécurité afin d'éviter les erreurs de manipulation ou le contournement de Solaris Resource Manager.

Pour modifier l'attribut sgroup, l'utilisateur doit posséder l'un des privilèges suivants :

• être le superutilisateur ;

• avoir un indicateur uselimadm activé ;

• avoir un indicateur admin activé et être chef de groupe pour le noeud limite à modifier.

Un noeud limite orphelin ne peut être le père d'autres noeuds limites. Voir "Noeuds limites orphelins".

Base de données des limites endommagée

Une base de données des limites endommagée est un problème important pour l'administrateur. Aucun symptôme ne permet de déterminer avec certitude si la base a été endommagée, mais certains indices peuvent indiquer une telle situation.

Si la base de données est endommagée, l'administrateur doit en restaurer une version valide et rétablir la configuration correspondante. 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).

Pour en savoir davantage sur la détection et la correction d'une base de données des limites endommagée, voir "Base de données des limites endommagée".

Temps de connexion d'un terminal non actualisé

La cause probable est que le programme limdaemon(1MSRM) n'est pas en cours d'exécution. limdaemon met périodiquement à jour les attributs d'usage et cumulatif dans la catégorie de terminal pour tous les utilisateurs en session. Normalement, il devrait être démarré depuis le script init.d(4) de Solaris Resource Manager.

Des utilisateurs dépassent souvent des limites

Il existe plusieurs causes probables : -

• La limite administrative de l'utilisateur est trop basse pour ses besoins.

• L'attribut d'usage ne décroît pas. L'administrateur est chargé de s'assurer que le décroissement est appliqué aux catégories de périphérique pour toutes les ressources renouvelables (incluant la catégorie de terminal). Normalement, cela est effectué en exécutant régulièrement la commande limdaemon(1MSRM). Si le décroissement n'est pas appliqué à une ressource renouvelable, l'attribut d'usage de cette ressource continue à croître jusqu'à ce que sa limite soit atteinte.

• L'intervalle entre les exécutions de limdecay est trop long. La fréquence d'exécution de limdaemon(1MSRM) doit être définie en fonction de la granularité de l'intervalle de décroissement le plus court.

• L'attribut de décroissement d'une ressource renouvelable est trop petit ou l'intervalle est trop grand. Si le décroissement d'une ressource renouvelable pendant un intervalle donné est fixé à une valeur inférieure au taux de consommation habituel de cette ressource, l'attribut d'usage augmentera progressivement jusqu'à ce que la limite soit atteinte.

Le système est lent

Processus du noeud limite racine

Aux fins de la gestion du système, les processus reliés au noeud limite racine obtiennent pratiquement toutes les ressources d'UC demandées. Par conséquent, si un processus d'UC est relié au noeud racine, il peut monopoliser et ralentir, voire même arrêter les processus des autres noeuds limites.

Pour éviter ce genre de problème, les précautions ci-après peuvent être prises :

• Pour l'utilisation normale, l'administrateur doit toujours ouvrir une session sur l'un de ses propres noeuds et non sur le noeud racine. S'il doit se relier au noeud racine, il ne doit pas exécuter d'applications faisant usage intensif de l'UC, par exemple, des compilateurs. Pour se servir d'une UID de superutilisateur sans se relier au noeud racine, l'administrateur peut utiliser la commande su(1).

• Les scripts init.d(4) devraient être modifiés pour utiliser le programme srmuser(1SRM) en vue de relier tous les démons à des noeuds limites qui leur appartiennent, ce qui évite de les relier (par héritage) au noeud limite racine.

Un programme exécuté en tant que setuid-root n'est pas automatiquement relié au noeud limite. Normalement, le processus demeure relié au noeud limite du père qui l'a créé, et seule l'UID en cours est changée.

Ressources d'unité centrale non contrôlées par Solaris Resource Manager

Solaris Resource Manager contrôle uniquement l'usage de l'UC par les processus de la classe d'ordonnancement SHR. Si des demandes excessives d'une priorité supérieure sont faites par d'autres classes d'ordonnancement, spécialement les classes temps réel (RT) et système (SYS), SHR peut ordonnancer seulement avec les ressources restantes de l'UC.

L'utilisation de la classe RT génère un conflit avec les fonctions de gestion de système de Solaris Resource Manager. Les processus en temps réel obtiennent un accès complet au système afin qu'ils puissent transmettre des réponses en temps réel (habituellement de l'ordre de quelques microsecondes). Les processus exécutés dans la classe SHR ont par définition une priorité inférieure à celle de tout processus en temps réel, sur lesquels Solaris Resource Manager n'a aucun contrôle. Les processus en temps réel peuvent facilement consommer toutes les ressources disponibles, privant Solaris Resource Manager de ressources à attribuer aux autres processus.

le serveur NFS est l'un des services exécuté exclusivement dans la classe SYS. Solaris Resource Manager ne peut contrôler les démons NFS, car ils sont exécutés dans SYS. La capacité de Solaris Resource Manager à attribuer des ressources de processeur peut être réduite sur les systèmes offrant un service NFS étendu.

Même si des processus exécutent du code de noyau (à l'intérieur d'un appel système), les règles de priorité de tranche de temps habituelles ne s'appliquent pas. La plupart des appels système exécuteront seulement une certaine partie de leurs tâches avant d'atteindre un point de préemption. Cependant, si le système subit une charge élevée d'appels système plus intensifs, cela peut causer une diminution de la réactivité globale, ce qui est hors de la portée de contrôle d'une classe d'ordonnancement.

Si le système manque de mémoire réelle, le goulot d'étranglement d'E-S résultant de l'accroissement du taux d'erreurs de page et des échanges de processus augmente la consommation des ressources de l'UC par le noyau. Des temps d'attente d'E-S importants peuvent indiquer des pertes de capacité d'UC. Encore une fois, cela est hors de la portée d'une classe d'ordonnancement.

La classe d'ordonnancement SHR est un ordonnanceur à temps partagé (TS) qui utilise la même gamme de priorité globale que les ordonnanceurs TS et IA. Il n'est pas recommandé de combiner l'utilisation de SHR avec TS et IA, sauf pour transférer tous les processus dans ou depuis la classe SHR. L'utilisation du système avec une combinaison de processus des classes SHR et TS diminuera la qualité de l'ordonnancement dans les deux classes. Pour cette raison, Solaris Resource Manager empêche les processus non racine de se déplacer ou de déplacer d'autres processus vers les classes TS ou IA. La classe RT fait appel à une autre gamme de priorité et peut être utilisée avec la classe SHR de la même façon que les classes TS et IA.

Si des processus exécutés par racine contiennent du code utilisant l'appel système priocntl(2) directement au lieu de la routine de bibliothèque setpriority(3C) pour ajuster les priorités des processus, ils peuvent transférer les processus cibles dans une autre classe d'ordonnancement (habituellement TS). Le code de la routine setpriority(3C) tient compte du fait que l'interface priocntl(2) avec SHR est binairement compatible avec celle de TS, et contourne ainsi le problème. L'option -c de ps(1) ou l'option -d de priocntl(1) peut être utilisée pour afficher la classe d'ordonnancement des processus.

Le même problème se manifeste avec les processus de privilège racine qui utilisent priocntl(2) explicitement pour gérer l'appartenance de classe d'ordonnancement des processus.

Messages inhabituels

Des messages sont envoyés à tout utilisateur ayant atteint une limite. Par conséquent, si une limite de groupe est atteinte, le chef de groupe et tous les utilisateurs des niveaux inférieurs de la hiérarchie d'ordonnancement du groupe recevront un message d'avertissement.

Si une limite est atteinte alors qu'un utilisateur est relié à un autre noeud limite, cet utilisateur ne recevra pas de message, mais tous les autres le recevront. La source du problème peut ne pas être apparente pour le groupe concerné.

Noeuds limites orphelins

Un noeud limite orphelin n'a pas de noeud limite père. Cela doit être pris en compte par l'administrateur, car Solaris Resource Manager empêche les processus de se relier à un noeud limite orphelin ou dont l'arbre d'ordonnancement comporte un ascendant orphelin.

Le noyau vérifie les changements apportés à l'attribut sgroup afin d'éviter la création d'orphelins suite à des modifications non valides au père du groupe d'ordonnancement.

Le principal effet d'un noeud limite orphelin est qu'il devient impossible d'y relier des processus. Aucun processus n'y étant relié, le noeud limite ne peut pas être utilisé pour ouvrir une session, et toute tentative avec le compte correspondant échouera.

La méthode la plus facile pour l'administrateur de détecter les noeuds limites orphelins consiste à utiliser la commande limreport(1SRM) avec l'identificateur d'orphelin intégré. La commande :

% limreport orphan - uid sgroup lname

indiquera l'UID, le père du groupe d'ordonnancement et le compte des utilisateurs ayant des noeuds limites orphelins. L'attribut sgroup peut être utilisé pour repérer les noeuds limites se trouvant à la racine d'une section orpheline de l'arbre.

Lorsque l'administrateur découvre un noeud orphelin, la première étape consiste à repérer la racine de la section orpheline dans l'arbre d'ordonnancement puisqu'il s'agit du noeud limite devant être relié. Si la racine de la section orpheline n'est pas identifiée correctement, seule une partie de la section orpheline sera reliée à l'arbre.

Une fois la racine de la section orpheline identifiée, l'administrateur disposant de privilèges suffisants peut utiliser la commande limadm(1MSRM) pour associer l'attribut sgroup du noeud limite orphelin de premier niveau à un noeud limite valide dans l'arbre. Le noeud orphelin sera relié à l'arbre en tant que membre du groupe dont le chef est le noeud limite valide. limadm vérifie si le père du nouveau groupe d'ordonnancement peut être activé, ce qui assure que le noeud limite modifié ne sera plus orphelin.

L'administrateur peut aussi créer un utilisateur dont l'UID est identique à celle de l'attribut sgroup du noeud orphelin, ce qui reliera automatiquement la section orpheline de l'arbre.

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.