Chapitre 10 Dépannage

Le but de ce chapitre est de vous à aider à diagnostiquer les problèmes relatifs à l'utilisation de Solaris Resource Manager.

Pour obtenir de l'assistance, contactez votre fournisseur Sun.

Problèmes concernant l'utilisateur

Un utilisateur ne peut pas ouvrir une session

• 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 peut exister, mais il 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 au superutilisateur.

Bien que l'utilisateur puisse ouvrir une session sur le système, il n'existe pas de noeud limite correspondant à l'UID de l'utilisateur (un noeud limite n'a pas été défini pour ce compte utilisateur), le problème est identifié par un message indiquant qu'aucune information sur les limites n'est disponible. Reportez-vous à la section "Noeuds limites orphelins".

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 atteinte. Parfois, les utilisateurs ne prennent pas connaissance de ces messages et ne sont pas au courant de la cause du problème. Le système leur semblera simplement se comporter anormalement. Toutefois, 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 aux utilisateurs, 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 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".

Les utilisateurs dépassent souvent les limites

Il existe plusieurs causes probables :

• La limite administrative d'un 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. 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.

• La période de décroissance est trop longue. La fréquence d'exécution de limdaemon 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.

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 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é.

Le temps de connexion d'un terminal n'est pas actualisé

La cause probable est que le programme limdaemon 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 de Solaris Resource Manager.

Problèmes de performance

Processus reliés au 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 :

• L'administrateur doit toujours ouvrir une session sur l'un des noeuds limites créés en vue d'une utilisation normale et non se relier au 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 peuvent être changés pour utiliser le programme srmuser pour relier tous les démons à leurs propres noeuds limites, de façon qu'ils ne soient pas reliés (par héritage) au noeud limite root. Cependant, cette solution ne peut pas être recommandée sur une base générale. Elle peut créer des problèmes, puisqu'un grand nombre de fichiers doivent être modifiés, et la pratique peut interdire l'intégration ultérieure des correctifs dans un système. Une solution n'imposant pas cette tâche est à l'étude.

  Pour Solaris Resource Manager versions 1.1 et 1.2, les scripts sbin_rc2 et sbin_rc3 fournis dans le répertoire /usr/srm/unsupport peuvent être utilisés pour résoudre partiellement ce problème.

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 centaines de 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 pas 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 interactif (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 de bibliothèque setpriority tient compte du fait que l'interface priocntl 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 de superutilisateur qui utilisent priocntl(2) explicitement pour gérer l'appartenance de classe d'ordonnancement des processus.

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 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 pour associer l'attribut sgroup du noeud limite orphelin de premier niveau à un noeud limite valide dans l'arbre d'ordonnancement. 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 pères 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). Lorsque le noyau découvre une boucle de groupe, il 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. La boucle n'ayant ni début ni fin, le noyau ne peut déterminer quel est le noeud limite supérieur. 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érieures à ceux auxquels ils auraient normalement droit.

Cause

Les boucles de groupe sont évitées par limadm 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.

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".

Règlement des conflits d'UID

Pour vérifier si les UID assignées par le système à srmidle, srmlost et srmother n'entrent pas en conflit avec des UID existantes, entrez :

# /usr/bin/egrep 41\|42\|43 /etc/passwd

En cas de conflit, vous pouvez changer les UID en modifiant les fichiers /etc/passwd et /etc/shadow.

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é, Ce sont :

• 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 pendant une panne de système, notamment en ce qui concerne la facturation du temps de connexion, peut être défectueux.

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, 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 révèle que la base de données des limites a été endommagée. 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 sa connexion est refusée. 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. Ainsi le noeud limite qui est supprimé n'est pas le seul à être touché : les noeuds limites orphelins le sont également (pour plus de détails, voir "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 des limites subitement.

• 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 afin de demander la liste des noeuds limites ayant des attributs dont les valeurs se situent dans une plage de valeurs connue. Si des valeurs figurant à l'extérieur de cette plage sont signalées, une altération a eu lieu. limreport peut également servir à dresser la liste des noeuds limites dont l'attribut 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.

Correction

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 et limadm. 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 des limites 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 le Chapitre 5. 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 est interrompu, peu importe la raison, tous les utilisateurs en session ne sont plus facturés pour leur temps de connexion. En outre, lorsque limdaemon est redémarré, les utilisateurs en session continuent à utiliser leur terminal gratuitement. Cela s'explique par le fait que le démon utilise les avis d'ouverture de session fournis par login 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 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. Mettez 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.