Bonjour à tous,
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ? 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 :
Bonjour à tous,
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ? 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 :
Bonjour à tous,
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ? 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 :
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ?
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]
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.
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 ?
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).
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ?
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]
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.
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 ?
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).
Est-ce que je suis le seul à avoir des problèmes avec les
noyaux de testing ?
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]
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.
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 ?
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).
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'
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'
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'
Étienne Mollier a écrit :- 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.
- 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.
$ 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).
Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i 'spectre|isolation'
[ 0.000000] Kernel/User page tables isolation: enabled
Étienne Mollier a écrit :
> - 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.
> - 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.
> $ 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).
Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i 'spectre|isolation'
[ 0.000000] Kernel/User page tables isolation: enabled
Étienne Mollier a écrit :- 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.
- 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.
$ 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).
Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i 'spectre|isolation'
[ 0.000000] Kernel/User page tables isolation: enabled
Bonsoir,
Joël Bertrand, le 2018-02-07 :Étienne Mollier a écrit :- 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.
Intéressant, la piste d'un bloc défectueux stockant un morceau
de ces fichiers à l'air sérieuse. Est ce que vous pouvez
artificiellement déclencher le problème en lisant contenu de ces
fichiers, à coups de dd ou de base64 par exemple ?
# base64 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
Si besoin, vous pouvez retrouver la trace du fichier
mod_reqtimeout.so à coup de find :
# find / -xdev -name mod_reqtimeout.so- 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.
Je comprend. Si vous pouvez contacter du monde sur place pour
aider au dépannage, il se pourrait que ce ne soit pas du temps
perdu.
Si cette piste n'est pas concluante, alors je sèche. Il
resterait à tester les rustines contre les vulnérabilités des
processeurs, mais je ne suis pas convaincu.
Bonsoir,
Joël Bertrand, le 2018-02-07 :
Étienne Mollier a écrit :
- 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.
Intéressant, la piste d'un bloc défectueux stockant un morceau
de ces fichiers à l'air sérieuse. Est ce que vous pouvez
artificiellement déclencher le problème en lisant contenu de ces
fichiers, à coups de dd ou de base64 par exemple ?
# base64 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
Si besoin, vous pouvez retrouver la trace du fichier
mod_reqtimeout.so à coup de find :
# find / -xdev -name mod_reqtimeout.so
- 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.
Je comprend. Si vous pouvez contacter du monde sur place pour
aider au dépannage, il se pourrait que ce ne soit pas du temps
perdu.
Si cette piste n'est pas concluante, alors je sèche. Il
resterait à tester les rustines contre les vulnérabilités des
processeurs, mais je ne suis pas convaincu.
Bonsoir,
Joël Bertrand, le 2018-02-07 :Étienne Mollier a écrit :- 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.
Intéressant, la piste d'un bloc défectueux stockant un morceau
de ces fichiers à l'air sérieuse. Est ce que vous pouvez
artificiellement déclencher le problème en lisant contenu de ces
fichiers, à coups de dd ou de base64 par exemple ?
# base64 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.8
Si besoin, vous pouvez retrouver la trace du fichier
mod_reqtimeout.so à coup de find :
# find / -xdev -name mod_reqtimeout.so- 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.
Je comprend. Si vous pouvez contacter du monde sur place pour
aider au dépannage, il se pourrait que ce ne soit pas du temps
perdu.
Si cette piste n'est pas concluante, alors je sèche. Il
resterait à tester les rustines contre les vulnérabilités des
processeurs, mais je ne suis pas convaincu.