Causes d'une indisposition periodique d'un serveur

Vincent Hiribarren <vynce@alea.invalid> écrit:

Les données sont :

- système d'exploitation Linux Debian
- le serveur semble indiponible d'environ 10h jusqu'à une heure du matin
- aucun problème réseau ne semble transparaitre d'après l'architecture
réseau environnante
- l'uptime du serveur semble correct, c'est à dire que malgré les
indisponibilités, il a pourtant l'air de bien fonctionner

Est ce qu'il y a des processus qui tournent durant l'indisponibilité ?
Que disent les logs ? Si les incidents sont prévisibles, programmez
un shutdown une fois pendant la période d'indisponibilité pour voir si
vous récupérez la main.

- ça ne peut pas venir d'un problème de configuration

On dit toujours ça.

- il m'est impossible d'avoir en ce moment un accès physique au serveur,
bien que je puisse l'administrer à distance

Cette périodicité me fait penser à un problème de chaleur : le serveur
n'est pas dans une salle climatisée, et il fait plutôt chaud en ce
moment... Donc il est possible que le matériel souffre un peu.

En général, la machine reboote en cas de grosse chaleur.

J'ai déjà quelques pistes pour pouvoir tester périodiquement le disque
dur et le CPU.

Si le disque dur est défaillant, le système est sensé le loguer. Si
le CPU déraille, la machine reboote ou panique car les programmes,
dont le noyau font n'importe quoi.

Mais allez savoir pourquoi, je me dis que je ferai bien de pouvoir
tester aussi *physiquement* la carte réseau (donc avec autre chose que
des ping ou des "arping").

"netstat -i" indique s'il y a des erreurs sur le réseau. Il faut
vérifier que les compteurs d'erreur ne s'incrémentent pas. Il est
possible que, sur Linux, on ai plus de détails sur la nature des
erreurs avec "ifconfig".

Les erreurs peuvent provenir de l'environement (si le réseau est
saturé, par exemple)

Y a-t-il un moyen pas trop compliqué de faire cela automatiquement ? Je
précise que je n'ai pas accès au web (donc je n'ai notamment pas accès
aux archives). Et je rappelle que je n'ai qu'un accès distant au
serveur.

Faites une liste des commandes que vous voulez lancer et mettez la
dans la crontab.

Est ce qu'il y a des processus qui tournent durant l'indisponibilité ?

Oui.

Que disent les logs ?

Problèmes d'accès réseau, justement.
Genre "named" qui a des problèmes d'accès à d'autres serveurs.

Si les incidents sont prévisibles, programmez
un shutdown une fois pendant la période d'indisponibilité pour voir si
vous récupérez la main.

Euh..... dans la mesure du possible, je préfère éviter tout shutdown,
comme je le disais il ne m'est pas possible d'avoir pour l'instant un
accès physique. Et si ça fait complètement taire la machine, il me sera
encore plus dur de voir ce qu'il se passe.

- ça ne peut pas venir d'un problème de configuration

On dit toujours ça.

:-)
Disons que la config n'a pas été touché ça fait un bon moment, et que
ces problèmes sont apparus du jour au lendemain.

Cette périodicité me fait penser à un problème de chaleur : le serveur
n'est pas dans une salle climatisée, et il fait plutôt chaud en ce
moment... Donc il est possible que le matériel souffre un peu.

En général, la machine reboote en cas de grosse chaleur.

Oui, mais peut-être que la machine est en elle-même suffisamment
résistante, mais pas d'autres composants, comme la carte réseau. C'est
pour cela que je pensais à cette dernière.

J'ai déjà quelques pistes pour pouvoir tester périodiquement le disque
dur et le CPU.

Si le disque dur est défaillant, le système est sensé le loguer. Si
le CPU déraille, la machine reboote ou panique car les programmes,
dont le noyau font n'importe quoi.

Oui, c'est entre autre pour cela que j'avais écarté dans mon esprit ces
possibilités, mais bon, comme d'une part on me l'a conseillé, et que
d'autre part ça ne peut pas faire de mal...

Mais allez savoir pourquoi, je me dis que je ferai bien de pouvoir
tester aussi *physiquement* la carte réseau (donc avec autre chose que
des ping ou des "arping").

"netstat -i" indique s'il y a des erreurs sur le réseau. Il faut
vérifier que les compteurs d'erreur ne s'incrémentent pas.

Mmhhh. Mais ça je le sais qu'il y a des erreurs : j'ai en ce moment un
script qui ping régulièrement le serveur à partir d'une autre machine.
C'est ce qui me permet de voir que la machine est à nouveau disponible
au cours de la nuit. Et justement les processus réseau tournant sur la
machine ont des problèmes d'accès réseau aussi.

Il est
possible que, sur Linux, on ai plus de détails sur la nature des
erreurs avec "ifconfig".

Peut-être. A voir, effectivement.

Les erreurs peuvent provenir de l'environement (si le réseau est
saturé, par exemple)

Non non, pas de problème de ce côté là (je sais, "on dit ça", mais j'ai
d'autres moyens de m'en assurer :-) ), et à la rigueur c'est plutôt une
période de non saturation en ce moment.
Par contre, comme je pense que le problème peut venir de la carte
réseau, je me dis qu'il est aussi peut-être possible que le problème
vienne du port particulier du switch où elle est branché (court-circuit
ou autre ???). Mais un autre poste branché sur un autre port de ce
switch fonctionne parfaitement bien, lui.

Y a-t-il un moyen pas trop compliqué de faire cela automatiquement ? Je
précise que je n'ai pas accès au web (donc je n'ai notamment pas accès
aux archives). Et je rappelle que je n'ai qu'un accès distant au
serveur.

Faites une liste des commandes que vous voulez lancer et mettez la
dans la crontab.

Oui, mais cron je connaissais :-)
C'est un test "physique" des différentes cartes, automatiquement et
logiciellement, qui m'intéresserait, et savoir s'il existe une commande
pour faire cela :)

Merci pour tout.

On Fri, 01 Aug 2003 13:14:16 +0200, Vincent Hiribarren wrote:

C'est un test "physique" des différentes cartes, automatiquement et
logiciellement, qui m'intéresserait, et savoir s'il existe une commande
pour faire cela :)

Regarde là:
- http://www.scyld.com/diag/index.html

Sinon, tu peux essayer de lancer, et logger, regulierement un traceroute
et voir où ça bloque ...

Si tu crois vraiement que c'est un pb avec la carte tu peux aussi essayer
d'arreter l'interface et la remettre en marche, si ping passe pas alors
désactiver l'interface, décharger le driver (s'il est en module),
recharger le driver, et réactiver l'interface, mais c'est "dangereux" si
tu n'es pas sur place ...

C'est un test "physique" des différentes cartes, automatiquement et
logiciellement, qui m'intéresserait, et savoir s'il existe une commande
pour faire cela :)

Regarde là:
- http://www.scyld.com/diag/index.html

Je n'ai absolument pas d'accès web.
Mais il me semble que je connais ce site (c'est pas celui fait fait
Mii-tool ?).
Je vais transmettre à des amis qui pourront me décrire le contenu.

Sinon, tu peux essayer de lancer, et logger, regulierement un traceroute
et voir où ça bloque ...

Non, cà n'est pas un problème de routage : un poste qui est branché sur
le même switch marche très bien, c'est d'ailleurs à partir de ce poste
que l'essentiel des tests est fait (et le problème ne vient pas non plus
de ce poste là car d'autres tests ont été faits à partir d'autres
serveurs sur des réseaux différents).

Si tu crois vraiement que c'est un pb avec la carte

Une personne qui a réussit à se déplacer pour voir ça semble confirmer
ma pensée.

tu peux aussi essayer
d'arreter l'interface et la remettre en marche, si ping passe pas alors
désactiver l'interface, décharger le driver (s'il est en module),
recharger le driver, et réactiver l'interface, mais c'est "dangereux" si
tu n'es pas sur place ...

Euh, oui, éteindre / rallumer tout ce qui concerne le réseau alors que
justement, mon seul moyen de communication est le réseau... je préfère
éviter :-)

En tout cas merci pour l'url donné plus haut, je vais essayer de voir si
ça peut m'être utile.

Vincent Hiribarren <vynce@alea.invalid> écrit:

Est ce qu'il y a des processus qui tournent durant l'indisponibilité ?

Oui.

Normalement ? il ne sont pas bloqués en attente de disque ou autre ?

Comme ça, je ne sais pas, mais les logs se remplissent au fur et à
mesure, donc à priori tout est bon. Enfin, j'essaierai de mieux vérifier
ça, mais le comportement actuel semble montrer que rien n'est bloqué.

Que disent les logs ?

Problèmes d'accès réseau, justement.
Genre "named" qui a des problèmes d'accès à d'autres serveurs.

Il est possible qu'on ne puisse pas se connecter dessus à cause d'un
problème de résolution de nom.

Non, ça n'est pas aussi simple :)
Des tests avec l'adresse IP direct ont été faits, bien évidemment.
Je parlais de "named" pour exemple de processus.

Utilise un resolver exterieur

... et de toute manière le DNS secondaire marche au poil.

- ça ne peut pas venir d'un problème de configuration
On dit toujours ça.

:-)

Disons que la config n'a pas été touché ça fait un bon moment, et que
ces problèmes sont apparus du jour au lendemain.

Ça n'est pas significatif.

Oui, mais quand même...

Oui, mais peut-être que la machine est en elle-même suffisamment
résistante, mais pas d'autres composants, comme la carte réseau. C'est
pour cela que je pensais à cette dernière.

Un bon système devrait loguer tous les problèmes d'accès au materiel.

Oui, et bien à priori les logs n'indiquent rien de ce genre. Mais je ne
sais pas exactement comment sont loggués les problèmes matériels et ce
qui est exactement logué.
C'est pour cela que je pensais à des choses comme faire des "lspci"
régulièrement... si cette méthode peut marcher et rapporte des résultats
probants.

"netstat -i" indique s'il y a des erreurs sur le réseau. Il faut
vérifier que les compteurs d'erreur ne s'incrémentent pas.

Mmhhh. Mais ça je le sais qu'il y a des erreurs : j'ai en ce moment un
script qui ping régulièrement le serveur à partir d'une autre machine.
C'est ce qui me permet de voir que la machine est à nouveau disponible
au cours de la nuit. Et justement les processus réseau tournant sur la
machine ont des problèmes d'accès réseau aussi.

Des erreurs en emission ou en reception ?
Des erreurs de ligne ou des paquets jetés ?
Que dit 'netstat -i' ?

Là il est indispo, et je n'aurai pas d'accès réseau du we, donc pour
actuellement, je sais qu'il y a des erreurs en émission. En réception...
je vois mal comment le voir, je n'ai aucun processus en "attente active"
quand le serveur est indiponible. Bien sûr j'ai un inetd et autres qui
tournent, mais comme je ne peux pas les titiller quand la machine est
indisponible.... eux ne se rendent compte de rien. Comme si la machine
était déconnectée.

Un ping vers la machine ne marche pas, tous les paquets sont perdus.

Par contre, comme je pense que le problème peut venir de la carte
réseau, je me dis qu'il est aussi peut-être possible que le problème
vienne du port particulier du switch où elle est branché (court-circuit
ou autre ???). Mais un autre poste branché sur un autre port de ce
switch fonctionne parfaitement bien, lui.

Déjà c'est un switch, ce qui devrait limiter les dégats. Comment sont
configurés les ports ? 100M, 10M, auto ? half-duplex, full-duplex,
auto ?

100 full. Il est bien up.

La carte est t'elle configurée de la même manière ?
L'auto-négociation est à éviter.

Ca, je ne sais pas. J'essaierai de voir, mais à priori pas de problème
de ce côté là. En quoi l'auto-négociation ferait en sorte de bloquer la
carte sur une période d'une dizaine d'heures ? Surtout que ça a marché
plusieurs années jusque là ?

Y a t'il des erreurs sur le port du switch ?

Il m'est impossible de le savoir mais je me pose aussi la question (cf
le paragraphe cité un peu plus haut).

Et comme je ne peux que tester à distance la carte réseau, je me
préoccupe plutôt de celle-là pour l'instant puisqu'elle est accessible.

"Vincent Hiribarren" <vynce@alea.invalid> a écrit dans le message de
news:3F2A77A2.B0B1448C@alea.invalid...
|
| > Vincent Hiribarren <vynce@alea.invalid> écrit:
| > >> Est ce qu'il y a des processus qui tournent durant l'indisponibilité
?
| > >
| > > Oui.
| >

dans les log as tu des choses genre link up link down ?

tu peux essayer des stat snmp et tu vera si il y a qq chose qui se passe au
niveau du trafic en monitorant les packet en erreur, et emis/recu

avec snmp tu peux aussi monitorer la temperature (cf mrtg....)

Vincent Hiribarren <vynce@alea.invalid> écrit:

Non, ça n'est pas aussi simple :)
Des tests avec l'adresse IP direct ont été faits, bien évidemment.
Je parlais de "named" pour exemple de processus.

Les services d'accès on tendance à faire des résolution du nom de la
machine qui se connecte.