| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Dépannage de problèmes courants dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Dépannage de problèmes courants dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Gestion des informations sur les pannes système (tâches)
2. Gestion des fichiers noyau (tâches)
3. Dépannage du système et des problèmes logiciels (tâches)
Procédure à suivre en cas de panne système
Collecte des données de dépannage
Liste de contrôle de résolution d'une panne système
Affichage des messages système
Affichage des messages système
Personnalisation de la journalisation des messages système
Personnalisation de la journalisation des messages système
Activation de la messagerie de la console distante
Utilisation de la messagerie de la console auxiliaire pendant les transitions de niveau d'exécution
Activation d'une console auxiliaire (distante)
Affichage de la liste des consoles auxiliaires
Activation d'une console auxiliaire (distante) après la réinitialisation du système
Dépannage des problèmes d'accès aux fichiers
Résolution des problèmes liés aux chemins de recherche (Command not found)
Diagnostic et correction des problèmes liés au chemin de recherche
Modification des propriétés de fichier et de groupe
Résolution des problèmes d'accès aux fichiers
Identification des problèmes d'accès réseau
4. Dépannage de divers problèmes système et logiciels (tâches)
Les sections ci-après décrivent les fonctionnalités du système de messagerie dans Oracle Solaris.
Les messages système s'affichent sur le périphérique de la console. Le texte de la majorité des messages système ressemble à ceci :
[ID ID message utilitaire. priorité]
Par exemple :
[ID 672855 kern.notice] syncing file systems...
Si le message a été créé dans le noyau, le nom du module de noyau s'affiche. Par exemple :
Oct 1 14:07:24 mars ufs: [ID 845546 kern.notice] alloc: /: file system full
Lorsqu'un système tombe en panne, il peut afficher un message sur la console du système, par exemple :
panic: error message
Moins souvent, ce message peut être affiché à la place du message d'erreur grave :
Watchdog reset !
Le démon de journalisation des erreurs syslogd enregistre automatiquement les différents avertissements et erreurs système dans des fichiers de messages. Par défaut, la plupart de ces messages système s'affichent sur la console du système et sont stockés dans le répertoire /var/adm. Vous pouvez définir l'emplacement de stockage de ces messages en configurant la journalisation des messages système. Pour plus d'informations, reportez-vous à la rubrique Personnalisation de la journalisation des messages système. Ces messages peuvent vous avertir des problèmes que rencontre le système, par exemple un périphérique sur le point d'échouer.
Le répertoire /var/adm contient plusieurs fichiers de messages. Les messages les plus récents résident dans le fichier /var/adm/messages (et dans messages.*), tandis que les plus anciens se trouvent dans le fichier messages.3. Après une période de temps (généralement tous les dix jours), un nouveau fichier messages est créé. Le fichier messages.0 est renommé messages.1, messages.1 est renommé messages.2 et messages.2 est renommé messages.3. Le fichier /var/adm/messages.3 actuel est supprimé.
Le répertoire /var/adm stockant de gros fichiers qui contiennent les messages, les vidages sur incident et autres données, il peut consommer une grande quantité d'espace disque. Pour éviter que le répertoire /var/adm ne devienne trop volumineux et pour vous assurer que les vidages sur incident ultérieurs pourront être enregistrés, vous devez supprimer régulièrement les fichiers inutiles. Vous pouvez automatiser cette tâche en utilisant le fichier crontab. Pour plus d'informations sur l'automatisation de cette tâche, reportez-vous à la section Suppression des fichiers de vidage sur incident du manuel Administration d’Oracle Solaris 11.1 : Périphériques et systèmes de fichiers and Chapitre 4, Tâches de planification du système (tâches) du manuel Gestion des informations système, des processus et des performances dans Oracle Solaris 11.1.
$ dmesg
ou utilisez la commande more pour afficher un écran de messages à la fois.
$ more /var/adm/messages
Exemple 3-1 Affichage des messages système
L'exemple suivant illustre la sortie de la commande dmesg sur un système Oracle Solaris 10.
$ dmesg Mon Sep 13 14:33:04 MDT 2010 Sep 13 11:06:16 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning] ... Sep 13 11:12:55 sr1-ubrm-41 last message repeated 398 times Sep 13 11:12:56 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning] ... Sep 13 11:15:16 sr1-ubrm-41 last message repeated 139 times Sep 13 11:15:16 sr1-ubrm-41 xscreensaver[25520]: ,,, Sep 13 11:15:16 sr1-ubrm-41 xscreensaver[25520]: ... Sep 13 11:15:17 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning]... . . .
Voir aussi
Pour plus d'informations, reportez-vous à la page de manuel dmesg(1M).
La rotation des fichiers journaux du système s'effectue à l'aide de la commande logadm à partir d'une entrée du fichier crontab racine. Le script /usr/lib/newsyslog n'est plus utilisé.
La rotation des journaux système est définie dans le fichier /etc/logadm.conf. Ce fichier comprend les entrées de rotation des journaux pour les processus tels que syslogd. Par exemple, une entrée du fichier /etc/logadm.conf indique que le fichier /var/log/syslog fait l'objet d'une rotation hebdomadaire sauf si le fichier est vide. Le fichier syslog le plus récent devient syslog.0, le fichier le plus récent suivant devient syslog.1, et ainsi de suite. Huit fichiers journaux syslog antérieurs sont conservés.
Le fichier /etc/logadm.conf contient également l'horodatage de la dernière rotation de journal effectuée.
Vous pouvez utiliser la commande logadm pour personnaliser la journalisation du système et ajouter une journalisation supplémentaire dans le /etc/logadm.conf selon les besoins.
Par exemple, pour une rotation des journaux d'accès et d'erreur Apache, utilisez les commandes suivantes :
# logadm -w /var/apache/logs/access_log -s 100m # logadm -w /var/apache/logs/error_log -s 10m
Dans cet exemple, le fichier access_log Apache fait l'objet d'une rotation lorsqu'il atteint une taille de 100 Mo, avec un suffixe .0, .1, (et ainsi de suite), de façon à conserver 10 copies de l'ancien fichier access_log . Le fichier error_log fait l'objet d'une rotation lorsqu'il atteint une taille de 10 Mo avec les mêmes suffixes et le même nombre de copies que le fichier access_log .
Les entrées /etc/logadm.conf des exemples de rotation précédents du journal Apache ressemblent à l'exemple suivant :
# cat /etc/logadm.conf . . . /var/apache/logs/error_log -s 10m /var/apache/logs/access_log -s 100m
Pour plus d'informations, reportez-vous à la page de manuel logadm(1M).
Vous pouvez utiliser la commande logadm en tant que superutilisateur ou en assumant un rôle équivalent (avec les droits de gestion des journaux). Avec le RBAC (contrôle d'accès basé sur les rôles), vous pouvez accorder aux utilisateurs non root le privilège de conserver les fichiers journaux en fournissant un accès à la commande logadm.
Par exemple, ajoutez l'entrée suivante au fichier /etc/user_attr pour accorder à l'utilisateur andy la possibilité d'utiliser la commande logadm :
andy::::profiles=Log Management
Vous pouvez capturer d'autres messages d'erreur générés par plusieurs processus système en modifiant le fichier /etc/syslog.conf. Par défaut, le fichier /etc/syslog.conf oriente de nombreux messages de processus système vers les fichiers /var/adm/messages. Les messages de panne et d'initialisation sont également stockés ici. Pour visualiser les messages /var/adm, reportez-vous à la rubrique Affichage des messages système.
Le fichier /etc/syslog.conf comporte deux colonnes séparées par des tabulations :
facility.level ... action
Utilitaire ou source système du message ou de la condition. Peut prendre la forme d'une liste d'utilitaires séparés par des virgules. Les valeurs des utilitaires sont répertoriées dans le Tableau 3-2. Niveau indique la gravité ou priorité de la condition à journaliser. Les niveaux de priorité sont répertoriés dans le Tableau 3-3.
Vous ne devez pas placer deux entrées pour le même utilitaire sur la même ligne, si les entrées sont pour différentes priorités. Définir une priorité dans le fichier syslog indique que tous les messages de cette priorité ou d'une priorité supérieure sont journalisés, le dernier message ayant la priorité. Pour un utilitaire et un niveau donnés, syslogd correspond à tous les messages de ce niveau et de tous les niveaux supérieurs.
Le champ d'action indique l'endroit où les messages sont transmis.
L'exemple suivant présente des lignes extraites d'un fichier /etc/syslog.conf par défaut.
user.err /dev/sysmsg user.err /var/adm/messages user.alert `root, operator' user.emerg *
Cela signifie que les messages utilisateur suivants sont automatiquement enregistrés :
Les erreurs de l'utilisateur s'affichent sur la console et sont également enregistrées dans le fichier /var/adm/messages.
Les messages utilisateur nécessitant une action immédiate (alert) sont envoyés aux utilisateurs root et aux utilisateurs operator.
Les messages d'urgence de l'utilisateur sont envoyés aux utilisateurs.
Remarque - Placer les entrées sur des lignes séparées peut entraîner la journalisation des messages dans le désordre si une cible de journal est spécifiée plusieurs fois dans le fichier /etc/syslog.conf . Notez que vous pouvez spécifier plusieurs sélecteurs dans une même entrée de ligne, en les séparant par un point-virgule.
Les sources de condition d'erreur les plus courantes sont indiquées dans le tableau suivant. Les priorités les plus courantes sont présentées dans le Tableau 3-3 par ordre de gravité.
Tableau 3-2 Utilitaires source des messages syslog.conf
|
Remarque - Le nombre d'utilitaires syslog qui peuvent être activés dans le fichier /etc/syslog.conf est illimité.
Tableau 3-3 Niveaux de priorité des messages syslog.conf
|
Reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
$ pfedit /etc/syslog.conf
Exemple 3-2 Personnalisation de la journalisation des messages système
Cet exemple d'utilitaire /etc/syslog.conf user.emerg envoie les messages utilisateur d'urgence à l'utilisateur root et aux différents utilisateurs.
user.emerg `root, *'
Les nouvelles fonctionnalités de console décrites ci-dessous améliorent le dépannage des systèmes distants :
La commande consadm vous permet de sélectionner un périphérique de série comme console auxiliaire (ou distante). A l'aide de la commande consadm, un administrateur système peut configurer un ou plusieurs ports série pour afficher les messages redirigés de la console et accueillir les sessions sulogin lorsque le système passe d'un niveau d'exécution à un autre. Cette fonction vous permet d'accéder à un port série avec un modem pour surveiller les messages de la console et participer aux transitions d'état init. (Pour plus d'informations, reportez-vous à la rubrique sulogin(1M) et aux procédures détaillées qui suivent.)
Alors que vous pouvez vous connecter à un système à l'aide d'un port configuré comme console auxiliaire, il s'agit principalement d'un périphérique de sortie qui affiche des informations qui sont également visibles sur la console par défaut. Si des scripts d'initialisation ou d'autres applications lisent ou écrivent depuis et vers la console par défaut, l'écriture en sortie s'affiche sur toutes les consoles auxiliaires, mais l'entrée est uniquement lisible à partir de la console par défaut. Pour plus d'informations sur l'utilisation de la commande consadm pendant une session de connexion interactive, reportez-vous à la section Recommandations relatives à l'utilisation de la commande consadm au cours d'une session de connexion interactive.
La sortie de la console est maintenant constituée des messages du noyau syslog écrits dans un nouveau pseudo périphérique, /dev/sysmsg. En outre, les messages de démarrage du script rc sont écrits dans /dev/msglog. Auparavant, tous ces messages étaient écrits dans /dev/console.
Les scripts qui orientent la sortie de la console vers /dev/console doivent être modifiés vers /dev/msglog si vous souhaitez afficher les messages des scripts dans les consoles auxiliaires. Les programmes référençant /dev/console doivent être explicitement modifiés pour utiliser syslog() ou strlog() si vous souhaitez que les messages soient redirigés vers un périphérique auxiliaire.
La commande consadm exécute un démon pour surveiller les périphériques de la console auxiliaire. Tout périphérique d'affichage désigné comme console auxiliaire qui se déconnecte, se bloque ou perd sa porteuse, est supprimé de la liste des périphériques de la console auxiliaire et n'est plus actif. L'activation d'une ou de plusieurs consoles auxiliaires ne désactive pas l'affichage des messages sur la console par défaut ; les messages continuent à afficher sur /dev/console.
Gardez à l'esprit les points suivants lors de l'utilisation de la messagerie de la console auxiliaire pendant les transitions de niveau d'exécution :
La saisie ne peut pas provenir d'une console auxiliaire si la saisie utilisateur est prévue pour un script rc exécuté lorsqu'un système est en cours d'initialisation. La saisie doit provenir de la console par défaut.
Le programme sulogin, appelé par init pour demander le mot de passe du superutilisateur lors du passage d'un niveau d'exécution à un autre, a été modifié de façon à envoyer l'invite du mot de passe du superutilisateur à chaque périphérique auxiliaire en plus de la console par défaut.
Lorsque le système est en mode monoutilisateur et qu'une ou plusieurs consoles auxiliaires sont activées à l'aide la commande consadm, une session de connexion à la console s'exécute sur le premier périphérique pour fournir le mot de passe de superutilisateur approprié à l'invite sulogin. Lorsque le mot de passe correct est reçu à partir d'un périphérique de la console, sulogin désactive la saisie à partir de tous les autres périphériques de la console.
Un message s'affiche sur la console par défaut et les autres consoles auxiliaires lorsque l'une de ces consoles suppose des privilèges monoutilisateur. Ce message désigne le périphérique qui joue le rôle de console en acceptant un mot de passe de superutilisateur correct. S'il existe une perte de la porteuse sur la console auxiliaire qui exécute le shell monoutilisateur, deux actions sont susceptibles de se produire :
Si la console auxiliaire représente un système au niveau d'exécution 1, le système passe au niveau d'exécution par défaut.
Si la console auxiliaire représente un système au niveau d'exécution S, le système affiche le message ENTER RUN LEVEL (0-6, s or S): sur le périphérique sur lequel la commande init s ou shutdown a été saisie à partir du shell. Si ce périphérique ne comporte aucune porteuse, vous devez rétablir la porteuse et utiliser le bon niveau d'exécution. La commande init ou shutdown ne réaffiche pas l'invite du niveau d'exécution.
Si vous êtes connecté à un système à l'aide d'un port série, et qu'une commande init ou shutdown est émise pour passer à un autre niveau d'exécution, la session de connexion est perdue, que ce périphérique corresponde à la console auxiliaire ou non. Il en va de même avec les versions dépourvues de consoles auxiliaires.
Lorsqu'un périphérique est sélectionné comme console auxiliaire à l'aide de la commande consadm, il reste défini comme tel jusqu'à ce que le système soit réinitialisé ou que la console auxiliaire soit désélectionnée. Toutefois, la commande consadm inclut une option qui permet de définir un périphérique en tant que console auxiliaire lors des réinitialisations du système (reportez-vous à la procédure qui suit pour des instructions détaillées).
Si vous voulez exécuter une session de connexion interactive en vous connectant à un système à l'aide d'un terminal connecté à un port série, puis en utilisant la commande consadm pour afficher les messages de la console du terminal, notez le comportement suivant :
Si vous utilisez le terminal pour une session de connexion interactive pendant que la console auxiliaire est active, les messages de la console sont envoyés aux périphériques /dev/sysmsg ou /dev/msglog.
Pendant que vous exécutez des commandes sur le terminal, la saisie est adressée à la session interactive et non à la console par défaut (/dev/console).
Si vous exécutez la commande init pour changer les niveaux d'exécution, le logiciel de console distante arrête la session interactive et exécute le programme sulogin. A ce stade, la saisie est acceptée uniquement à partir du terminal et traitée comme si elle provenait d'un périphérique de la console. Vous pouvez ainsi saisir le mot de passe du programme sulogin comme décrit dans la section Utilisation de la messagerie de la console auxiliaire pendant les transitions de niveau d'exécution.
Ensuite, si vous saisissez le mot de passe correct sur le terminal (auxiliaire), la console auxiliaire exécute une session sulogin interactive, verrouille la console par défaut et toutes les consoles auxiliaires concurrentes. Cela signifie que le terminal fonctionne essentiellement en tant que console système.
A partir de là, vous pouvez passer au niveau d'exécution 3 ou accéder à un autre niveau d'exécution. Si vous modifiez les niveaux d'exécution, sulogin s'exécute à nouveau sur tous les périphériques. Si vous quittez l'application ou définissez le système sur le niveau d'exécution 3, toutes les consoles auxiliaires ne sont plus capables de fournir des données. Elles redeviennent des périphériques d'affichage des messages de la console.
A mesure que le système monte, vous devez fournir des informations aux scripts rc sur le périphérique de la console par défaut. Ensuite, le programme login s'exécute sur les ports série et vous pouvez vous connecter à une autre session interactive. Si vous avez désigné le périphérique en tant que console auxiliaire, les messages de la console restent visibles sur le terminal, mais toutes les entrées du terminal sont transmises à la session interactive.
Le démon consadm ne commence à surveiller le port que lorsque vous avez ajouté la console auxiliaire avec la commande consadm. A des fins de sécurité, les messages de la console sont redirigés uniquement jusqu'à la chute de la porteuse ou l'annulation de la sélection du périphérique de la console auxiliaire. Cela signifie que la porteuse doit être établie sur le port pour que vous puissiez utiliser correctement la commande consadm.
Pour plus d'informations sur l'activation d'une console auxiliaire, reportez-vous à la page de manuel consadm(1m).
Reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
# consadm -a devicename
# consadm
Exemple 3-3 Activation d'une console auxiliaire (distante)
# consadm -a /dev/term/a # consadm /dev/term/a
Reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
# consadm -a -p devicename
Cette opération permet d'ajouter le périphérique à la liste des consoles auxiliaires persistantes.
# consadm
Exemple 3-4 Activation d'une console auxiliaire (distante) après la réinitialisation du système
# consadm -a -p /dev/term/a # consadm /dev/term/a
Reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
# consadm
Exemple 3-5 Désactivation d'une console auxiliaire (distante)
# consadm -d /dev/term/a # consadm
|