Re: BUG depuis deux versions du noyau de testing
Étienne Mollier a écrit :
> 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 ?
Je ne sais pas, je n'ai pas eu l'idée de tester.
>> 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 ?
La machine est à 500 bornes, je ne peux pas faire cela facilement. Mais
je n'ai pas d'erreur dans les logs concernant les disques.
> - 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 ?
Non, rien d'autre.
> 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/*
Ça ne donne rien. Le noyau est un 4.14.0-3-amd64 #1 SMP Debian
4.14.13-1 (2018-01-14).
> 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'
Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i
'spectre\|isolation'
[ 0.000000] Kernel/User page tables isolation: enabled
Cordialement,
JB
Reply to: