Depuis plusieurs mois, un de mes serveurs (une Dedibox) s’arrête de temps à autres, alors qu’il n’y a que dovecot installé dessus. Le serveur devient inaccessible après un certain temps de fonctionnement (de quelques heures à plusieurs jours), sans possibilité de connexion SSH ni réponse aux pings. Un redémarrage est alors obligatoire.
Après le freeze, plus rien n’est écrit sur le disque (pas de logs), l’erreur ressemble donc à un kernel panic. Cependant, les mécanismes permettant de détecter les crashs au niveau du noyau et de dumper l’état de la mémoire (ou même de redémarrer automatiquement) ne fonctionnent pas.
J’ai fait de nombreux tests pour savoir d’où vient le problème, et il apparaît que ce problème :
- n’est pas dû à un problème matériel (d’après les tests matériels proposés sur les serveurs),
- n’est pas dû à une charge importante du serveur (le serveur tombe alors qu’il n’y a quasiment pas de charge CPU, j’ai déjà vu la machine freezer avec un top sous les yeux),
- apparaît sur le serveur où est installé dovecot (lorsque postfix est sur un serveur et dovecot sur un second, uniquement le second tombe),
- n’est pas dû à un dysfonctionnement logiciel (aucune trace de dysfonctionnement dans les logs du noyau ni dans les logs de dovecot),
- n’est pas dû à ce serveur en particulier (le même dysfonctionnement est également apparu sur d’autres serveurs Online équivalents),
- n’est pas dû à un manque de RAM ou d’espace disque,
- n’est pas reporté par d’autres utilisateurs de dovecot, d’après les nombreux forums et sites de rapports d’erreurs que nous avons consultés,
- n’est pas reproductible :/.
J’ai évidemment essayé avec diverses versions du noyau (à peu près tous les 3.x), diverses version de dovecot 2, et le résultat est le même. En activant tous les logs possibles et imaginables dans dovecot, je n’ai rien trouvé d’intéressant, le freeze a l’air totalement aléatoire.
Pour montrer jusqu’où je suis déjà allé pour traquer ce bug, j’ai également testé des paquets de la mort qui peuvent affecter ma carte réseau, suite à la lecture de cet article. Mon serveur est vulnérable (uniquement pour un paquet envoyé d’une machine sur elle-même, heureusement pour notre hébergeur !), mais cela fait redémarrer la machine (et pas freezer), ce n’est donc pas le même problème.
À noter que j’ai la même configuration matérielle et logicielle sur d’autres serveurs (sans dovecot, mais même noyau et même distrib gentoo), et que tout fonctionne à merveille.
J’en ai déjà parlé avec des gens d’Online qui ont trituré mon serveur sans rien trouver d’intéressant.
Si vous avez la moindre idée ou la moindre question sur ce problème, n’hésitez pas, je serai heureux de profiter de vos lumières !
# RAM
Posté par Marotte ⛧ . Évalué à 4.
Quels tests ? La RAM a été testée à coup de Memtest ?
[^] # Re: RAM
Posté par liZe . Évalué à 1.
Je ne connais pas la suite de tests matériels d’Online, mais je suppose qu’ils ont testé la RAM. De toute façon, comme j’ai eu le même problème avec trois serveurs différents, je doute que le problème soit matériel.
# Sécurisation ?
Posté par barret benoit . Évalué à 1.
Côté utilisation des ressources système :
qu'en disent les iowait, iotop, etc… ?
Côté sécurisation des services ouverts sur le net :
ça m'est arrivé à l'époque de subir des scans/attaques brutes sur des dedibox…
http ssh et smtp aussi.
Tout ça pour dire, qu'en disent les logs systèmes ?
quels ports sont ouverts sur ta machine ?
[^] # Re: Sécurisation ?
Posté par liZe . Évalué à 1.
Comme le trafic est vraiment faible, je n’ai pas regardé en détail l’activité disque, mais je vais jeter un coup d’œil.
Au niveau des services ouverts, il y a IMAP (TLS) et SSH (sur un autre port que le 22, pour éviter les bots). Aucune activité louche ni sur l’un ni sur l’autre d’après les logs.
# Netconsole
Posté par Skanx (site web personnel) . Évalué à 5.
Pas une solution en soi, mais ça peut aider pour le diagnostic. Netconsole est un module qui permet d'envoyer les messages du kernel via udp, par exemple vers un syslog. Ca permet donc de récupérer les oops, les messages de panic, etc. d'une machine distante sauf bien sûr si le problème se situe côté réseau.
La doc : https://www.kernel.org/doc/Documentation/networking/netconsole.txt
[^] # Re: Netconsole
Posté par liZe . Évalué à 1.
Merci, je ne sais pas comment j’ai pu passer à côté de ça ! J’installe de ce pas !
[^] # Re: Netconsole
Posté par liZe . Évalué à 1.
C’était vraiment bien tenté. Après avoir mis en place netconsole et avoir pu lire les messages du noyau sur un autre serveur, j’ai patiemment attendu que ça freeze. Ça a freezé. Et à mon grand désarroi, le brave netconsole n’a pas pipé mot…
On pourrait croire que le problème vient donc de la carte réseau, mais sachant que je n’ai rien de plus dans les logs sur mon disque, j’ai de sérieux doutes. Je commence à perdre le peu d’espoir qu’il me reste encore :/.
En tout cas merci beaucoup pour netconsole, c’est drôlement pratique et ça me servira sans doute un jour.
[^] # Re: Netconsole
Posté par Skanx (site web personnel) . Évalué à 1.
Dommage :-(
Tu n'aurais pas la possibilité d'avoir un KVM sur IP, avec ce serveur ? Sur les dernières Dedibox classic et haut-dessus, il me semble qu'on a la main sur l'iLO (si c'est un serveur HP) ou le iDRAC (si c'est un Dell).
Même si ce n'est pas inclus dans l'offre de base, tu as peut-être la possibilité de le commander ? Mais je ne sais pas si on peut prendre cette option pour une durée limitée, ou si il faut le conserver jusqu'à la résiliation du serveur…
# Disque/FS ?
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
Un serveur IMAP ca bourrine bien le disque (j'en ai tué plusieurs comme ça).
Je tenterais des choses genre iozone.
# Même problème
Posté par Renaud Casenave-Péré . Évalué à 1.
J'ai le même problème, sur un serveur online également, qui est apparu quand j'ai mis debian à jour de squeeze à wheezy. Je n'ai plus qu'un apache et un ejabberd qui tournent dessus, je ne pense donc pas que ce soit le serveur qui ne tienne pas la charge. Je pensais que c'était la mise à jour qui a foiré, je comptais essayer de réinstaller le tout mais je n'ai pas encore pris le temps.
# approche simple
Posté par Salk . Évalué à 0.
Tu peux éventuellement tenter d'installer l'agent Zabbix et activer un maximum de tests pour garder trace de l'activité de ton bazard avant perte de contact, et notamment, savoir s'il est encore vivant quand tu as perdu contact avec lui.
Instinctivement, je regarderais du côté de la conf IPv4/IPv6
[^] # Re: approche simple
Posté par liZe . Évalué à 1.
Il n’est plus vivant, je n’ai plus aucune activité stockée sur le disque à partir de la perte de contact.
J’avais aussi essayé de désactiver l’IPv6 au niveau du noyau, mais ça ne change rien.
# ce que j'en dis
Posté par NeoX . Évalué à 2.
1 et 2 permettent de dire que ce n'est pas le materiel
3 et 4 se contredisent mais confirment un point : c'est là ou se trouve dovecot.
il ne te reste plus qu'a lancer dovecot en mode debug, ou avec la config par defaut,
ou la config minimaliste avant de remettre tes options une par une,
car de ce que tu racontes, c'est quand meme lui qui fout la merde sur ta machine.
[^] # Re: ce que j'en dis
Posté par liZe . Évalué à 0.
Oui, c’est un peu contradictoire. Ce que je voulais dire par là, c’est que les logs de dovecot et du noyau ne disent rien de particulier, et que ce n’est pas à première vue dovecot qui prend 100% du CPU / fait crasher le noyau / prend toute la mémoire.
Il faudrait en effet que je lance dovecot avec une config minimaliste, mais comme c’est sur un serveur de prod, c’est un peu compliqué. Je pourrais monter un autre serveur avec une config minimaliste, mais il faudrait générer du trafic aléatoire dessus pour essayer de le refaire tomber, et comme je n’ai pas de cas de test pour reproduire, ça risque d’être très long et très fastidieux.
Étant donné que je ne vois pas comment dovecot pourrait faire tomber un serveur (autrement que par le load, la mémoire et l’accès disque, ce qui n’est pas le cas ici), et que cependant c’est bien dovecot qui semble être à l’origine du problème, je commence sérieusement à croire que c’est un type de paquet réseau particulier qui fait freezer la machine (et qu’IMAP fait souvent passer ce type de paquets).
Pour ceux que ça intéresse : je m’oriente vers ce bug rapporté pour RedHat, qui ressemble furieusement au mien.
[^] # Re: ce que j'en dis
Posté par barret benoit . Évalué à 1.
ça correspond à ton modèle de carte réseau ?
[^] # Re: ce que j'en dis
Posté par liZe . Évalué à 0.
Oui !
[^] # Re: ce que j'en dis
Posté par barret benoit . Évalué à 1.
alors t'as changé de noyau ou recompilé le module ?
tiens-nous au courant !
[^] # Re: ce que j'en dis
Posté par liZe . Évalué à 0.
Comme il était proposé dans le rapport de bug, j’ai forcé la gestion d’énergie de la carte réseau pour ne plus dépendre de ce que le bios disait.
Et ça n’a rien changé.
Du coup, pour ne pas sombrer dans la démotivation, j’ai désactivé une tripotée de modules dans le noyau (dont l’ACPI et l’ASPM, je vais tuer des ours blancs), recompilé le tout et redémarré le serveur. J’attends le prochain crash, je vous tiendrai au courant !
[^] # Re: ce que j'en dis
Posté par liZe . Évalué à 0.
Le temps que j’écrive le message, le serveur est tombé.
J’avoue que je suis bientôt à court d’idées…
[^] # Re: ce que j'en dis
Posté par barret benoit . Évalué à 1.
Comme dit dans les commentaires du rapport de bug, la version du noyau pour le e1000 qui corrige le bug est la >= 1.2.10…
Donc, je sais pas quelle distrib' tu as sur ton serveur, mais tu :
- upgrade ton noyau avec un package (EL ou backport)
- installe les "kernel headers", et en téléchargeant les sources mises à jour dudit module, et les compilant…
[^] # Re: ce que j'en dis
Posté par liZe . Évalué à 1.
La version de mon noyau contient une version du driver déjà bien plus récente que la 1.2.10 (je suis sous gentoo, et j’ai tenté presque tous les noyaux 3.x jusqu’aux 3.8.x).
# Tentative désespérée
Posté par liZe . Évalué à 1.
Comme Online fournit la possibilité de démarrer en mode « secours » avec une Ubuntu live, j’ai eu l’idée bizarre de démarrer mes services sur la distribution live après un chroot, et de voir ce qui se passe sur ce brave noyau 3.2. Si tout fonctionne un petit bout de temps, je serai quasiment sûr que le problème vient de mon noyau. Mauvaise idée pas très orthodoxe, mais au point où j’en suis…
[^] # Re: Tentative désespérée
Posté par NeoX . Évalué à 2.
parce que tu as un noyau custom ?
alors oui, en effet, cela pourrait venir de là,
mais une installation à l'identique de dovecot, sur une distribution "binaire" avec le noyau de la distrib t'aurais surement aussi donner ces infos.
de plus tu disais precedemment que le probleme se produisait chez un hebergeur ou chez un autre, mais toujours avec dovecot.
ca veut dire que dans les deux cas c'etait des gentoo avec des noyaux personnalisés ?
[^] # Re: Tentative désespérée
Posté par liZe . Évalué à 1.
Le serveur vient de tomber avec le liveCD, le problème ne vient donc pas de mon noyau custom.
Pour être exact, le problème est toujours chez le même hébergeur, mais avec trois serveurs différents (avec la même configuration logicielle et matérielle). Maintenant, je sais que le serveur crashe avec mon noyau Gentoo custom, mais également avec le noyau de la Ubuntu fourni pour le mode « rescue ».
De deux choses l’une :
Je penche pour la première solution, sachant que certains sous Debian ont eu des problèmes en passant de squeeze à wheezy sur le même matériel.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.