Causes d'une indisposition periodique d'un serveur
7 réponses
Vincent Hiribarren
Bien le bonjour à tous !
J'ai un gros problème avec un serveur auquel j'ai accès (à distance).
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
- ça ne peut pas venir d'un problème de configuration
- 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.
J'ai déjà quelques pistes pour pouvoir tester périodiquement le disque
dur et le CPU.
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").
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.
J'avais pensé à faire à l'aide de cron des "lspci" périodique, me disant
que la carte réseau, si elle tombe, ne serait alors plus reconnue par
cette commande... mais je peux me tromper complètement ne connaissant
pas le fonctionnement concret de cette commande. Qu'en pensez-vous ? Et
il y a peut-être sûrement un moyen plus simple pour tester la
disponibilité physique de la carte réseau... Des idées ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent Wacrenier
Vincent Hiribarren é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.
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.
- 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.
Vincent Hiribarren
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.
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 :)
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.
root
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 :)
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 ...
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 :)
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 ...
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 :)
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 ...
Vincent Hiribarren
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 :)
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.
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 :)
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.
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 :)
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
Vincent Hiribarren é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> é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.
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.
[SauroN]
"Vincent Hiribarren" a écrit dans le message de news: | | > Vincent Hiribarren é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> 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" a écrit dans le message de news: | | > Vincent Hiribarren é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....)
Laurent Wacrenier
Vincent Hiribarren é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.
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.
