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

Posté par  .
Étiquettes :
0
8
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  (site web personnel, Mastodon) . É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  (site web personnel) . Évalué à 1.

    hang check activé ?

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # Uptime

    Posté par  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 1.

          c du raid hardware hp

          Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

        • [^] # Re: kernel.log, uptime

          Posté par  . É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  (site web personnel) . É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 - Ouvert à de nouvelles opportunités

  • # et la violence ? tu as essayé la violence ?

    Posté par  . É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.

  • # Femme de ménage

    Posté par  . Évalué à 4.

    à tester

    :D

  • # console

    Posté par  (site web personnel) . É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.