Re: BUG depuis deux versions du noyau de testing
Bonsoir,
Joël Bertrand, le 2018-05-02 :
> Est-ce que je suis le seul à avoir des problèmes avec les
> noyaux de testing ?
J'utilise un noyau compilé maison, mais pas de problème de mon
côté du temps où il était en version 4.14.13. Je n'ai pas
l'usage d'Apache 2 par contre.
> J'ai assez souvent la charge de mon serveur de test qui monte à
> plus de 500 (!) avec une occupation CPU de 0 et les logs
> remplis de :
>
> [226324.616534] BUG: Bad page map in process apache2 pte:00000080
[...]
> [226324.616593] file:mod_reqtimeout.so fault:ext4_filemap_fault [ext4] mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
> [226324.616597] CPU: 7 PID: 16832 Comm: apache2 Not tainted 4.14.0-3-amd64 #1 Debian 4.14.13-1
[...]
> [226324.616655] Disabling lock debugging due to kernel taint
[...]
> [233970.944487] file:liblber-2.4.so.2.10.8 fault:ext4_filemap_fault [ext4] mmap:ext4_file_mmap [ext4] readpage:ext4_readpage [ext4]
Apparemment, l'erreur rencontrée est suffisament sérieuse pour
teinter le noyau. Elle est provoquée lors de la montée en
mémoire du contenu de bibliothèques nécessaires au fonctionnement
d'apache2, ou tout du moins, du module concernant l'expiration
des requêtes... Mais peut-être aussi que tout ce qui se raporte
de près ou de loin à LDAP est concerné :
$ find /usr/lib/ -name 'liblber*'
[...]
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
$ dpkg -S /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
libldap-2.4-2:amd64: /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
> Aucun autre symptôme, pas de swap anormal. La machine en
> question est un i7 3770 avec 16Go de mémoire. Pas d'erreur
> mémoire (memtest ne renvoie strictement rien). Seule solution,
> redémarrer la machine.
Le problème ne viendrait donc pas de la mémoire, c'est toujours
ça de pris. Quand vous dites « aucun autre symptôme », le
service est-il toujours rendu par Apache ?
> Lorsque le système part en vrille comme ça, je me
> retrouve avec plus de 2000 processus (contre 300 à 350 en
> fonctionnement normal). Mais un ps ne rend jamais la main, ce
> qui fait que je n'arrive même pas à isoler le fautif. Je
> suspecte apache2 car le premier message d'erreur est toujours :
>
> Bad page map in process apache2
>
> Une idée ?
J'ai quelques idées de pertinence très inégale :
- Peut-être s'agit-il de problèmes de corruption de données sur
disque. Avez-vous eu l'occasion de contrôler l'état de la
partition système via fsck, ou l'état du ou des disques
sous-jacents ?
- Sinon, ça pourrait être un bug dans la pile d'appel au système
de fichier ext4, mais j'y crois moyennement. Le pilote ext4
n'a pas reçu de mise à jour particulière entre les noyaux
4.14.13 et 4.14.16 et étant donné sa large utilisation, ça se
serait probablement vu. Ou alors dans la gestion de la mémoire
virtuelle, ce qui pourrait expliquer le blocage de ps ?...
- Pour élargir un peu le spectre, est ce que les autres journaux
d'erreur mentionnent d'autres fichiers que mod_reqtimeout.so ou
liblber-2.4.so.2.10.8, ou bien est ce que toutes les erreurs
tournent autour de ces deux fichiers ?
Haricophile, le 2018-02-05 :
> Si c'était le kernel, je dirais un rapport avec le bugs Intel
> sur le calcul parallèle prédictif ? Un test en désactivant le
> patch je ne sais plus comment au démarrage (je n'ai pas suivi
> de près).
La remarque est pertinente étant donné la vitesse à laquelle les
patches ont dû être intégrés.
*À fin de débug* vous pouvez faire sauter le mécanisme en éditant
la commande de démarrage dans Grub. Appuyez sur E pour éditer,
puis modifiez la commande linux pour ajouter « pti=off » pour
faire sauter le mécanisme Kaiser, permettant de se prémunir
contre Meltdown, et « spectre_v2=off » pour couper les mécanismes
de Retpolines, permettant de se prémunir contre la seconde
variante de Spectre.
Si vous n'avez pas facilement la main sur la console au
démarrage, vous pouvez toujours placer ces options dans
/etc/default/grub, dans la variable GRUB_CMDLINE_LINUX et lancer
un update-grub.
Si le noyau est assez récent, vous pouvez contrôler l'état de
protection contre les vulnérabilités CPU comme suit:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
Sinon, il est aussi possible de consulter le journal de démarrage
du noyau pour vérifier l'état des patches via la commande
suivante :
$ sudo dmesg | grep -i 'spectre\|isolation'
*Rétablissez les patches de sécurité quand vous avez fini.*
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Reply to: