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
pmd:1764cb067
[226324.616541] addr:00007f777c571000 vm_flags:08000070 anon_vma:
(null) mapping:ffff96792bf664a0 index:1c2
[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.616598] Hardware name: System manufacturer System Product
Name/P8Q77-M2, BIOS 0224 08/17/2012
[226324.616599] Call Trace:
[226324.616609] dump_stack+0x5c/0x85
[226324.616614] print_bad_pte+0x1da/0x2a0
[226324.616617] unmap_page_range+0x7ce/0x9b0
[226324.616621] unmap_vmas+0x4c/0xa0
[226324.616625] exit_mmap+0x95/0x180
[226324.616630] mmput+0x54/0x140
[226324.616633] do_exit+0x287/0xb30
[226324.616636] ? handle_mm_fault+0xaa/0x1f0
[226324.616640] ? __do_page_fault+0x280/0x4e0
[226324.616642] do_group_exit+0x3a/0xa0
[226324.616645] SyS_exit_group+0x10/0x10
[226324.616649] system_call_fast_compare_end+0xc/0x6f
[226324.616651] RIP: 0033:0x7f77887a86d8
[226324.616652] RSP: 002b:00007ffd24a11318 EFLAGS: 00000246
[226324.616655] Disabling lock debugging due to kernel taint
[226324.694501] BUG: Bad rss-counter state mm:ffff967924cd6e40 idx:2 val:-1
[233970.944446] BUG: Bad page map in process sendmail-mta pte:00000080
pmd:1764cb067
[233970.944451] addr:00007f8907171000 vm_flags:08000070 anon_vma:
(null) mapping:ffff967987a86c50 index:94
[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 :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Haricophile
Le Mon, 5 Feb 2018 23:22:37 +0100, BERTRAND Joël a écrit :
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 :
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). Sinon pas d'idée, mais je ne suis pas un utilisateur intensif d'Apache.
Le Mon, 5 Feb 2018 23:22:37 +0100,
BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
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 :
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).
Sinon pas d'idée, mais je ne suis pas un utilisateur intensif d'Apache.
Le Mon, 5 Feb 2018 23:22:37 +0100, BERTRAND Joël a écrit :
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 :
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). Sinon pas d'idée, mais je ne suis pas un utilisateur intensif d'Apache.
=c3
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
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
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
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é :
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:
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
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
BERTRAND Jo=c3=abl
É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'
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:
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'
- 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.
Ça ne donne rien. Le noyau est un 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14).
D'accord, je m'en doutais, le répertoire n'est apparu qu'après publication des correction de Spectre pour le noyau 4.14. On peut toujours se fier à la sortie de dmesg néanmoins.
Kernel/User Page Table Isolation (PTI), le correctif contre Meldown est actif. Ne coupez ce mécano que dans le cadre de test! Si vous voulez poursuivre sur la piste du patch PTI : - Éditez /etc/default/grub pour modifier la variable comme suit : GRUB_CMDLINE_LINUX="pti=off" - Lancez la commande : # update-grub - Lancez un redémarrage de la machine : # reboot - Vérifiez l'activité du patch en consultant la sortie de : # dmesg | grep isolation À plus, -- Étienne Mollier
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 ?
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.
Ça ne donne rien. Le noyau est un 4.14.0-3-amd64 #1 SMP
Debian 4.14.13-1 (2018-01-14).
D'accord, je m'en doutais, le répertoire n'est apparu qu'après
publication des correction de Spectre pour le noyau 4.14. On
peut toujours se fier à la sortie de dmesg néanmoins.
- 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.
Ça ne donne rien. Le noyau est un 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14).
D'accord, je m'en doutais, le répertoire n'est apparu qu'après publication des correction de Spectre pour le noyau 4.14. On peut toujours se fier à la sortie de dmesg néanmoins.
Kernel/User Page Table Isolation (PTI), le correctif contre Meldown est actif. Ne coupez ce mécano que dans le cadre de test! Si vous voulez poursuivre sur la piste du patch PTI : - Éditez /etc/default/grub pour modifier la variable comme suit : GRUB_CMDLINE_LINUX="pti=off" - Lancez la commande : # update-grub - Lancez un redémarrage de la machine : # reboot - Vérifiez l'activité du patch en consultant la sortie de : # dmesg | grep isolation À plus, -- Étienne Mollier
BERTRAND Jo=c3=abl
Étienne Mollier a écrit :
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
Le fichier est parfaitement lisible (/usr est sur un disque en raid1 et ça m'étonnerait que ce soit un problème de bloc défectueux, à la limite un problème de système de fichiers...). Mais aucun des fichiers incriminés n'est illisible.
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.
Moi non plus... Je vais attendre que cela se reproduise (si cela se reproduira, je viens de passer les patches de buster qui viennent de me redémarrer apache2 sur une dépendance de bibliothèque). Cordialement, JKB
Étienne Mollier a écrit :
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 ?
Le fichier est parfaitement lisible (/usr est sur un disque en raid1 et
ça m'étonnerait que ce soit un problème de bloc défectueux, à la limite
un problème de système de fichiers...). Mais aucun des fichiers
incriminés n'est illisible.
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.
Moi non plus...
Je vais attendre que cela se reproduise (si cela se reproduira, je
viens de passer les patches de buster qui viennent de me redémarrer
apache2 sur une dépendance de bibliothèque).
- 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
Le fichier est parfaitement lisible (/usr est sur un disque en raid1 et ça m'étonnerait que ce soit un problème de bloc défectueux, à la limite un problème de système de fichiers...). Mais aucun des fichiers incriminés n'est illisible.
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.
Moi non plus... Je vais attendre que cela se reproduise (si cela se reproduira, je viens de passer les patches de buster qui viennent de me redémarrer apache2 sur une dépendance de bibliothèque). Cordialement, JKB
