Reboots intempestifs

Support Debian
#1

Hello !

J’utilise plusieurs serveurs Debian pour mon site. C’est ce qu’on m’avait conseillé à mes débuts, et j’avoue que j’ai appris (un peu de) Linux avec cette distribution, et j’avoue que ça marche plutôt bien. :slightly_smiling:

Ces serveurs sont tous loués chez OVH, et sont en Squeeze avec la source de paquets DotDeb rajoutée.

Généralement ces serveurs font tourner apache avec php et mysql, et là j’ai un souci qui je l’avoue m’embête considérablement : un de ces serveurs reboote de manière intempestive, plusieurs fois par jour.

Bien que j’aie appris pas mal de choses (en partant du monde windows), je me trouve dans l’incapacité de déterminer le pourquoi du comment de ces reboots, et je me permets donc de vous demander de l’aide. Merci d’avance ! :smiley:

Sur ce serveur, uname -a me dit 3.2.13-grsec-xxxx-grs-ipv6-64 #1 SMP Thu Mar 29 09:48:59 UTC 2012 x86_64 GNU/Linux.

D’installé, on a :

  • apache2 2.2.16-6+squeeze7
  • exim4 4.72-6+squeeze2
  • fail2ban 0.8.4-3+squeeze1
  • munin 1.4.5-3
  • mysql 5.5.25-1~dotdeb.0
  • php5 5.3.17-1~dotdeb.0
  • pureftpd 1.0.28-3+squeeze1

La commande lspci renvoie :
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)
00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 10)
03:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

La commande lsusb renvoie de son côté :
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Voilà le début de dmidecode :

[quote]SMBIOS 2.7 present.
61 structures occupying 2684 bytes.
Table at 0x000EB170.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Intel Corp.
Version: BLH6710H.86A.0119.2011.0523.1030
Release Date: 05/23/2011
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 KB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer:
Product Name:
Version:
Serial Number:
UUID: 327A7FA4-D829-11E0-8919-505054503030
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Intel Corporation
Product Name: DH67BL
Version: AAG10189-209
Serial Number: BTBL13700373
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer:
Type: Desktop
Lock: Not Present
Version:
Serial Number:
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: LGA1155
Type: Central Processor
Family:
Manufacturer: Intel Corporation
ID: A7 06 02 00 FF FB EB BF
Version: Intel® Core™ i5-2400 CPU @ 3.10GHz
Voltage: 1.7 V
External Clock: 100 MHz
Max Speed: 4000 MHz
Current Speed: 3100 MHz
Status: Populated, Enabled
Upgrade:
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: To Be Filled By O.E.M.
[/quote]

C’est un peu long mais j’en posterai volontiers l’output au besoin. :slightly_smiling:

Donc le problème est que cette machine reboote plusieurs par jour, et que je n’arrive pas à trouver la cause.

Je regarde dans syslog, mais la seule trace est le début des logs du reboot lui-même : rien n’est indiqué avant.

Par exemple ce jour je suis passé de :
Sep 24 13:54:27 named[2505]: error (unexpected RCODE REFUSED) resolving ‘78.0.214.80.in-addr.arpa/PTR/IN’: 62.201.159.99#53

À :
Sep 24 13:55:27 kernel: imklog 4.6.4, log source = /proc/kmsg started.
Sep 24 13:55:27 rsyslogd: [origin software=“rsyslogd” swVersion=“4.6.4” x-pid=“2385” x-info=“http://www.rsyslog.com”] (re)start
Sep 24 13:55:27 kernel: Initializing cgroup subsys cpuset
Sep 24 13:55:27 kernel: Linux version 3.2.13-grsec-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Thu Mar 29 09:48:59 UTC 2012
Sep 24 13:55:27 kernel: Command line: BOOT_IMAGE=/boot/bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/md1 ro quiet
etc.

Je me suis bien douté d’un problème hard avec la machine, mais…
Un boot en recovery mode de chez OVH a permis de stress-tester ram, cpu et hdd sans trouver de problème, et j’ai installé lm-sensors qui log régulièrement des températures qui semblent tout à fait correctes.

Voyez-vous dans ce que je poste des choses qui vous semblent évidentes et qui pourraient causer de tels redémarrages ?

Savez-vous comment je pourrais en savoir plus ? Comme je suis à distance, je n’ai pas de visuel écran pour le crash. : /

Si j’ai bien compris, la seule issue que j’aurais serait de modifier le grub pour inclure le dump de mémoire au crash avec kdump, et ensuite de remonter sur la pile avec crash… S’il le faut, je le ferai, mais j’ai peur de saloper la config de base de l’install Debian d’OVH - et le serveur étant bien sûr en prod, je ne voudrais pas risquer de tels soucis.

Merci pour toute idée qui me permettrait d’avancer là-dessus ! :blush:

#2

Le contenu de /var/log/dmesg ou /var/log/kern.log serait peut-être plus parlant que /var/log/syslog car ce dernier est trop “haut niveau” ; ce qui concerne le matériel se trouve plutôt dans un de ces deux fichiers (voire dans les .1.gz correspondants, selon la rotation des logs).

#3

Malheureusement, je n’ai pas trouvé d’indice dans ces deux logs.

Pour le plantage du jour référencé plus haut, on a :

kern.log

Sep 24 13:47:01 kernel: mdadm: sending ioctl 1261 to a partition!
Sep 24 13:55:27 kernel: imklog 4.6.4, log source = /proc/kmsg started.
Sep 24 13:55:27 kernel: Initializing cgroup subsys cpuset
Sep 24 13:55:27 kernel: Linux version 3.2.13-grsec-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Thu Mar 29 09:48:59 UTC 2012
Sep 24 13:55:27 kernel: Command line: BOOT_IMAGE=/boot/bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/md1 ro quiet

dmesg

Initializing cgroup subsys cpuset
Linux version 3.2.13-grsec-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Thu Mar 29 09:48:59 UTC 2012
Command line: BOOT_IMAGE=/boot/bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/md1 ro quiet

dmesg ne concerne que le dernier boot, n’est-ce pas ?

On trouve dans dmesg cette partie sur le système de fichier :
EXT3-fs (md1): error: couldn’t mount because of unsupported optional features (240)
EXT2-fs (md1): error: couldn’t mount because of unsupported optional features (244)
EXT4-fs (md1): INFO: recovery required on readonly filesystem
EXT4-fs (md1): write access will be enabled during recovery
usb 1-1: new high-speed USB device number 2 using ehci_hcd
EXT4-fs (md1): orphan cleanup on readonly fs
EXT4-fs (md1): ext4_orphan_cleanup: deleting unreferenced inode 314
EXT4-fs (md1): ext4_orphan_cleanup: deleting unreferenced inode 285
EXT4-fs (md1): ext4_orphan_cleanup: deleting unreferenced inode 283
EXT4-fs (md1): ext4_orphan_cleanup: deleting unreferenced inode 256
EXT4-fs (md1): ext4_orphan_cleanup: deleting unreferenced inode 255
EXT4-fs (md1): 5 orphan inodes deleted
EXT4-fs (md1): recovery complete
EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 9:1.
Freeing unused kernel memory: 632k freed

Mais à part ça… :confused:

#4

J’aurais dis comme toi: problème matériel. Mais si rien dans les logs, et passage OK des tests, tu peux pour l’instant abandonner cette piste.
Reste un bug kernel sur cette architecture. As tu essayé un autre kernel (plus ancien, ou plus récent).
Quel kernel recommende OVH ?

#5

Salut,

Histoire que cela soit clair, enfin, pour moi déjà … :033

Tel que tu l’indiques. Est ce dans le cas présent:

Un reboot intempestive du dit serveur ?

Ou …

Un reboot (suite à une détection ovh) suite à un incident, imposé par ovh ? (reboot/rescue ?)

#6

Les logs indique vraiment un redémarrage brutal. Visiblement, tu as une réparation du système de fichier qui semble suggérer que ça n’est pas le système qui a demandé le redémarrage (par exemple par un watchdog) mais la machine qui a redémarré toute seule. As tu signalé le problème à OVH (en général ils sont attentifs à ce genre de chose). En attendant, tu devrais mettre les mark par

$ModLoad immark
$MarkMessagePeriod 30

Qui te mettras une mark toutes les 30s dans ton syslog, tu auras une petite idée de la durée de l’interruption. (Gaffe tt de même, ton syslog va augmenter)

#7

Merci de votre sollicitude. :smiley:

En effet il semble que ce soit un redémarrage brutal. Je serais de base assez étonné que ça se produise suite à l’action d’un programme en fait.

Cela ne semble pas imposé par OVH, et je n’ai pas essayé d’autre noyau… Là j’avoue j’atteins ma limite : je ne sais pas changer le noyau. :blush:

Je peux tenter d’apprendre (j’imagine qu’il doit y avoir du tuto), mais est-ce une procédure complexe / délicate à faire sur un serveur en prod ?

edit: après vérif, on utilise le même noyau sur d’autres serveurs qui n’ont pas ce souci. Ca ne semble donc pas être dû a ça… Sauf si c’est une incompatibilité avec le matos, me direz-vous.

fran.b : j’ai placé le MARK, on verra ce que ça donnera d’ici demain.

#8

Salut,

[quote=“sruchet”]je ne sais pas changer le noyau. :blush:

Je peux tenter d’apprendre (j’imagine qu’il doit y avoir du tuto), mais est-ce une procédure complexe / délicate à faire sur un serveur en prod ?[/quote]

Quoi de plus simple … :083 Installation d’un noyau Debian chez ovh. … :wink:

* edit *

[quote=“fran.b”]Les logs indique vraiment un redémarrage brutal. Visiblement, tu as une réparation du système de fichier qui semble suggérer que ça n’est pas le système qui a demandé le redémarrage (par exemple par un watchdog) mais la machine qui a redémarré toute seule. As tu signalé le problème à OVH (en général ils sont attentifs à ce genre de chose). En attendant, tu devrais mettre les mark par

$ModLoad immark
$MarkMessagePeriod 30

Qui te mettras une mark toutes les 30s dans ton syslog, tu auras une petite idée de la durée de l’interruption. (Gaffe tt de même, ton syslog va augmenter)[/quote]

Ceci m’intéresse François!

Sûr quel fichier faut il jouer pour ce faire. :017

#9

Oooh merci. ^^

Entre temps j’ai appelé OVH et ils me conseillent un netboot sur un noyau sans l’extension grsec, je testerai ça d’ici mercredi (quand je pourrai être devant pour monitorer, quand même).

[quote]Ceci m’intéresse François!

Sûr quel fichier faut il jouer pour ce faire. :017[/quote]

Ah ça je peux le dire : c’est dans /etc/rsyslog.conf. Il faut redémarrer rsyslog après. :slightly_smiling:

#10

Re,

Je qualifie cela, comme un retour d’ascenseur … :wink:

#11

Installe le paquet munin, tu auras quelques graphiques et ainsi tu pourras voir si une ressource s’emballe ou pas (cpu, mem, loadavg, …).
Et puisque les serveurs sont chez OVH, tu as l’accès à RTM dans le manager, as-tu regardé si les graphiques OVH indiquent quelque chose avant ces coupures ?

#12

Hello !

Alors j’ai déjà Munin, mais il n’indique pas forcément de process qui s’emballe.

J’ai regardé pour la MARK et ça indique juste ce qu’on voyait, que ça cesse moins d’une minute avant les infos log de reboot.

On verra ce que ça donne dès que j’aurai pu tester avec un noyau différent…

#13

Bonjour,

je viens de m’inscrire car j’ai actuellement le même problème depuis quelques jours.
voyant que le topic et tout récent, je me demande si l’on doit y voir une simple coïncidence …
ayant fouiller tous les logs, passer en rescue pour effectuer tous les tests possible, on a rien trouver
les MRTG sont normaux, memtest, le raid etc… tout est ok

la machine tourne sans problème depuis plus de 6 mois, sur un noyau 3.2.13 grsec
et sans raison depuis vendredi soir, elle reboot brutalement

on a sortis la machine du load balancing, couper tous les cron etc…
donc le serveur est à vide, il ne reçoit aucun trafic, aucun script maison ne tourne, et pourtant il reboot encore

pour info
RBX4, premier reboot le vendredi 21 sept à 23h18, puis environ 2 autres par jours tout le week-end

#14

Salut,
Qu’en dit le support OVH ?

#15

Pas de souci apparent sur la machine, donc ils conseillent d’activer leurs sondes et de tenter d’utiliser la machine via un boot distant sur un noyau sans grsec, pour voir si ça change quelque chose.

C’est ce que je vais faire d’ici demain, et on va voir en effet !

edit: ah tiens je viens de noter une coincidence troublante… le maxxing d’eth0 à 100 mbits et les reboots semblent être liés.

CF cette surimposition des deux graphs de munin traffic eth0 + uptime :

Ca… Parle à quelqu’un ? :confused:

#16

Update: voilà t’y pas que les sondes d’OVH, une fois activées, me disent que le service DNS ne fonctionne pas (ou pas bien ?).

.---------------------------------------------------------------------------------------------------------------------------------------.
| OVH Service Monitoring [ALERT]
.-----------------±--------±-------±----------------±--------±--------------------------±-----------------------------------------.
| IP | Proto | Port | Time [sec] | Status | Timestamp | Reason
±----------------±--------±-------±----------------±--------±--------------------------±-----------------------------------------+
| xxxxxxxxxxxxx | dns | 53 | 0.000 | FAILURE | Thu Sep 27 18:00:02 2012 | Connection problem.
’-----------------±--------±-------±----------------±--------±--------------------------±-----------------------------------------’

.----------------------------------------------.
| OVH Service Monitoring [REMIND]
.-----------------±--------±-------±--------.
| IP | Proto | Port | Status
±----------------±--------±-------±--------+
| xxxxxxxxxxxxx | dns | 53 | FAILURE
’-----------------±--------±-------±--------’

Alors là je ne comprends plus.

J’ai moins de reboots intempestifs là, mais je vois que c’est toujours corrélé à cette pointe sur eth0 : qui dit pointe dit reboot.

Est-il possible que je sois victime d’attaques, peut-être en rapport avec le dns ? Mais à ce moment-là, comment s’en prémunir ? :confused:

#17

Salut,
Tu te sert du DNS pour répondre à des demandes venant de l’extérieur ?
Si non bloque le port avec iptables, que ton DNS ne serve que localhost - C’est l’option que j’ai choisie. Mes DNS sont paramétrés dans le panel d’OVH pas sur mon dédié.

Tu peux, avec logwatch avoir une idée assez précise et large de ce qui se passe sur ton DNS?

#18

J’avoue que je ne sais pas à quel point on peut faire appel à des URL par nom dans le code PHP… Ce serait sans doute la seule utilisation du DNS, non ?

Donc en ce cas je pourrais bloquer le port 53 pour l’extérieur ?

En effet logwatch m’informe de tout un tas de requêtes bizarres, du type :
Unmatched Entries
error (host unreachable) resolving ‘ns1.mobistar.be/A/IN’: 212.224.255.252#53: 1 Time(s)
error (host unreachable) resolving ‘ns1.mobistar.be/AAAA/IN’: 212.224.255.252#53: 1 Time(s)
error (host unreachable) resolving ‘ns2.mobistar.be/A/IN’: 212.224.255.252#53: 1 Time(s)
error (unexpected RCODE REFUSED) resolving ‘10.9.214.80.in-addr.arpa/PTR/IN’: 62.201.159.99#53: 1 Time(s)
error (unexpected RCODE REFUSED) resolving ‘101.108.68.68.in-addr.arpa/PTR/IN’: 72.13.80.2#53: 1 Time(s)
error (unexpected RCODE REFUSED) resolving ‘102.34.164.205.in-addr.arpa/PTR/IN’: 72.13.80.2#53: 1 Time(s)
error (unexpected RCODE REFUSED) resolving ‘107.0.214.80.in-addr.arpa/PTR/IN’: 62.201.159.99#53: 1 Time(s)
error (unexpected RCODE REFUSED) resolving ‘107.4.214.80.in-addr.arpa/PTR/IN’: 62.201.159.99#53: 1 Time(s)

ou encore :
success resolving ‘249.240.171.88.in-addr.arpa/PTR’ (in ‘240.171.88.in-addr.arpa’?) after disabling EDNS: 1 Time(s)
success resolving ‘249.44.238.82.in-addr.arpa/PTR’ (in ‘44.238.82.in-addr.arpa’?) after disabling EDNS: 1 Time(s)
success resolving ‘25.65.175.88.in-addr.arpa/PTR’ (in ‘65.175.88.in-addr.arpa’?) after disabling EDNS: 1 Time(s)
success resolving ‘25.84.230.82.in-addr.arpa/PTR’ (in ‘84.230.82.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)
success resolving ‘250.243.245.82.in-addr.arpa/PTR’ (in ‘243.245.82.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)
success resolving ‘251.1.83.156.in-addr.arpa/PTR’ (in ‘83.156.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)
success resolving ‘252.170.56.81.in-addr.arpa/PTR’ (in ‘170.56.81.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)
success resolving ‘252.233.176.88.in-addr.arpa/PTR’ (in ‘233.176.88.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)
success resolving ‘252.252.241.82.in-addr.arpa/PTR’ (in ‘252.241.82.in-addr.arpa’?) after reducing the advertised EDNS UDP packet size to 512 octets: 1 Time(s)

#19

On dirait en effet que tu es victime d’un scan automatique.
Et cela se traduit par un DOS.
Ferme un max de port et ne conserve que le strict nécessaire pour soulager ta machine.

#20

Salut,
Effectivement ton port 53 est très sollicité.
AU début j’avais ouvert mon DNS sur l’interface externe, mais en voyant les requêtes affluer, j’ai vite fermé.

En tout cas ça vaut le coup de tester!