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.moll...@mailoo.org>