Forum Linux.général Serveur qui reboot : raison ?

Posté par Clement33 le 08 juillet 2011 à 12:04.

Étiquettes :

juil.

2011

Salut à tous,

Mon logiciel de monitoring m'indique que mon serveur était indisponible hier à 15H42 et qu'il aurait redémarré...

Je consulte donc mon /var/log/syslog, et j'ai ceci :

    Jul  7 15:40:01 zimbra /USR/SBIN/CRON[31347]: (zimbra) CMD (/opt/zimbra/libexec/zmstatuslog > /dev/null 2>&1)
    Jul  7 15:40:01 zimbra /USR/SBIN/CRON[31352]: (root) CMD (ntpdate -su pool.ntp.org)
    Jul  7 15:42:01 zimbra /USR/SBIN/CRON[32275]: (zimbra) CMD (/opt/zimbra/libexec/zmstatuslog > /dev/null 2>&1)
    Jul  7 15:46:38 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 15:46:38 zimbra rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="3574" x-info="http://www.rsyslog.com"] restart

J'ai en effet un trou entre 15h42 et 15h46... Y'a t-il quelque chose qui me permettrait d'identifier la raison de ce trou (ou reboot ?) ?

Bonne journée !

# Panne de jus

Posté par Lol Zimmerli (site web personnel, Mastodon) le 08 juillet 2011 à 12:18. Évalué à 0.

S'il est configuré pour rebooter suite à une défaillance de l'approvisionnement électrique, c'est une piste possible.

Mais es-tu sûr qu'il a rebooté? (Regarde les logs ou uptime)

La gelée de coings est une chose à ne pas avaler de travers.
# c'est light!!!

Posté par nono14 (site web personnel) le 08 juillet 2011 à 12:19. Évalué à 1.

hang check activé ?

Système - Réseau - Sécurité Open Source
# Uptime

Posté par Clement33 le 08 juillet 2011 à 14:07. Évalué à 0.

@Lol Zimmerli : Dans les logs, il y a un trou entre 15h42 et 15h46 comme je l'ai précisé dans mon premier post...

Concernant l'uptime : 14:04:29 up 21:48, 1 user, load average: 0.24, 0.19, 0.16

Donc il a bien rebooté...

@nono14 : j'ai cherché sur google, et rien concernant Hang Check, je sais pas du tout ce que c'est.
# kernel.log, uptime

Posté par NeoX le 08 juillet 2011 à 14:09. Évalué à 1.

kernel.log te permettra de voir les dernieres activités kernel avant le reboot, ca peut etre une piste.

en effet, rien dans syslog ne veut pas dire que ca reboot, juste que rien n'est loggué

ensuite avec le uptime (ou top) tu sauras depuis quand ta machine a booté et donc s'il y a eu un reboot.

ensuite il faut chercher aussi qui etait connecté (commade last)
pour voir si ce n'est pas un reboot demandé par l'administrateur
- [^] # Re: kernel.log, uptime
  
  Posté par Clement33 le 08 juillet 2011 à 14:44. Évalué à -1.
  Comme je l'ai dit plus haut, l'uptime est de 21 heures, donc il a bien rebooté...
  
  Et dans /var/log/kern.log, j'ai ceci :
```
    Jul  6 00:10:32 zimbra kernel: [  127.253773] NFSD: starting 90-second grace period
    Jul  6 00:10:34 zimbra kernel: [  128.977521] bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
    Jul  6 00:10:34 zimbra kernel: [  128.979647] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Jul  6 00:10:37 zimbra kernel: [  133.116122]  CIFS VFS: cifs_read_super: get root inode failed
    Jul  6 00:10:45 zimbra kernel: [  141.387369] eth0: no IPv6 routers present
    Jul  6 06:25:04 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 06:25:03 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 15:46:38 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Initializing cgroup subsys cpuset
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Initializing cgroup subsys cpu
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Linux version 2.6.26-2-amd64 (Debian 2.6.26-19lenny2) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 02:23:12 UTC 2009
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Command line: root=/dev/cciss/c0d0p1 ro
    Jul  7 15:46:38 zimbra kernel: [    0.000000] BIOS-provided physical RAM map:
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 00000000df63f000 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df63f000 - 00000000df64c000 (ACPI data)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df64c000 - 00000000df64d000 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df64d000 - 00000000e4000000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fee10000 (reserved)
```
  Bizarrement, je n'ai rien entre 06:25 et 15:48... Et le reste des logs, on dirait qu'il démarre non ?
  
  Concernant une intervention humaine, non, cette possibilité est écartée :S.
  - [^] # Re: kernel.log, uptime
    
    Posté par Nasga le 08 juillet 2011 à 15:12. Évalué à 0.
    
    C'est un disque dur physique ou réseau (iscsi/nfs...) ?
    
    As tu un monitoring sur cette machine ? (nagios/munin/collectd/etc...)
    Si ce n'est pas le cas, je te conseille vivement d'installer une de ces solutions.
    
    Lorsque ton monitoring indique une défaillance, il faut vérifier la console si possible pour détecter un kernel panic/disque remonté en readonly/etc.
    
    Selon l'environnement, il est très simple de balancer un mail dans le rc.local pour être averti a chaque boot et de lancer un cron toutes les minutes qui log dans un fichier.
    - [^] # Re: kernel.log, uptime
      
      Posté par nono14 (site web personnel) le 08 juillet 2011 à 15:39. Évalué à 1.
      
      c du raid hardware hp
      
      Système - Réseau - Sécurité Open Source
    - [^] # Re: kernel.log, uptime
      
      Posté par Clement33 le 08 juillet 2011 à 16:41. Évalué à -2.
      
      Ces disques sont montés en cciss...
      
      J'ai Zabbix qui monitore mes serveurs, et il ne m'a juste indiqué que mon serveur était indisponible pendant 4 ou 5 minutes...
      
      Aucun autre moyen de voir clairement ce qui s'est passé ? :S
      - [^] # Re: kernel.log, uptime
        
        Posté par nono14 (site web personnel) le 08 juillet 2011 à 16:52. Évalué à 1.
        
        Pas assez de log, syslog planté, panne réseau ( carte, switch, cable, port down, ... ) entre le monitoring et la machine...
        
        Système - Réseau - Sécurité Open Source
# et la violence ? tu as essayé la violence ?

Posté par kuroineko le 08 juillet 2011 à 15:37. Évalué à 1.

Si ça ne marche pas, prends un plus gros marteau, si ça ne marche tjrs pas frappes plus fort, Si ça ne marche pas, prends un plus gros marteau, si ça ne marche tjrs pas frappes plus fort, si ça ne marche tjrs pas continues jusqu'à ce que soit ça fonctionne, soit ce soit intégralement détruit.
- [^] # Re: et la violence ? tu as essayé la violence ?
  
  Posté par Tuxologue le 21 août 2011 à 02:11. Évalué à 0.
  
  Lol
# Femme de ménage

Posté par Donk le 08 juillet 2011 à 16:16. Évalué à 4.

à tester

:D
# console

Posté par Krunch (site web personnel) le 08 juillet 2011 à 23:35. Évalué à 1.

Soit c'est un problème « externe » (panne électrique,...) soit c'est un kernel panic dont le message n'a pas eu le temps de se propager vers l'userland. Pour en savoir plus il faudrait les logs de la console au moment du problème. Si tu n'as pas la possibilité de logguer la console physiquement (via port série,...) tu peux toujours utiliser netconsole mais selon la combinaison distro/matériel/configuration ça peut causer plus de problèmes qu'autre chose.

Un examen de /proc (les panic* notamment) et des logs sar si tu les as peuvent aussi permettre d'éliminer l'un ou l'autre scénario mais ne donnera sans doute rien de catégorique.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.