Re: BUG depuis deux versions du noyau de testing

[BERTRAND Joël]

É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

Re: [MariaDB] Quel fichier de configuration modifier ?

[Étienne Mollier]

Ph. Gras, le 2018-02-08 :
> Salut la liste,

Bonsoir,

> d'après vous, quel fichier de configuration je devrais utiliser
> pour y apporter mes modifications perso ?

Si j'en crois les commentaires du fichier, alors je dirais, par
ordre de préférence :

> # 4. "~/.my.cnf" to set user-specific options.

Le fichier n°4 est tout indiqué pour les modifications qui
n'affectent que votre compte utilisateur.

> # 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.

Ranger des fichiers selon le motif n°3 est parfait pour les
modifications qui affectent votre serveur MariaDB.  Et puis, vous
pouvez donner des noms parlants à vos fichiers, comme memoire.cnf
ou reseau.cnf.  :-)

> # 2. "/etc/mysql/conf.d/*.cnf" to set global options.

Ranger des fichiers selon le motif n°2 est bien si vous voulez
maintenir la compatibilité avec MySQL, mais vous ne devriez pas y
utiliser les options spécifiques à MariaDB, tout dépend de vos
contraintes.

> # 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,

Il est peut-être préférable d'éviter de modifier ce fichier.  À
chaque mise à jour, vous seriez informé par dpkg que le fichier
de configuration du paquet à été modifié.  L'outil de mise à jour
vous invitera à inspecter la situation.

Si un gros changement dans la configuration est à prévoir lors
d'une mise à jour, le mainteneur devrait laisser un message dans
le paquet.  Ce message sera affiché au début des mises à jour,
après la phase de téléchargement.

Voilà mon humble avis, s'il peut vous apporter quelque lumières.

À plus,
-- 
Étienne Mollier 

Re: BUG depuis deux versions du noyau de testing

[É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 ?

# 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.


> > $ 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).

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.

> Root rayleigh:[/sys/devices/system/cpu] > dmesg | grep -i 'spectre\|isolation'
> [0.00] Kernel/User page tables isolation: enabled

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 

[MariaDB] Quel fichier de configuration modifier ?

[Ph. Gras]

Salut la liste,

d'après vous, quel fichier de configuration je devrais utiliser pour y apporter 
mes modifications perso ?
:/etc# ls -al mysql
-rw-r--r--  1 root root  869 août  10 21:07 mariadb.cnf
lrwxrwxrwx  1 root root   24 janv.  7 13:59 my.cnf -> /etc/alternatives/my.cnf

:/etc/mysql# ls -al ../alternatives
lrwxrwxrwx  1 root root   22 janv.  7 13:59 my.cnf -> /etc/mysql/mariadb.cnf

:/etc/mysql# cat mariadb.cnf
# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.

#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

D'avance merci pour vos avis avisés,

Ph. Gras

Re: BUG depuis deux versions du noyau de testing

[BERTRAND Joël]

É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.00] Kernel/User page tables isolation: enabled

Cordialement,

JB