Bonjour,
Le 20/03/2023 à 19:46, Olivier Allard-Jacquin a écrit :
>
> Bonjour,
>
> j'ai un problème avec nfsd que je n'arrive pas à résoudre, malgré
pas mal de recherches:
[...]
J'ai finalement résolu, non sans mal, mon problème de partage NFS
de partition non montée au démarrage.
***** Version courte *****:
Le problème venait du /etc/systemd/system/sddm.service , avec la ligne :
# 2023/01/22: Force all log to go to "noisy" journalctrl
#
https://unix.stackexchange.com/questions/696781/turn-off-logging-to-journald-for-specified-systemd-service
#
https://wiki.archlinux.org/title/Systemd/Journal#Per_unit_size_limit_by_a_journal_namespace
# In order to see noisy messages:
# journalctl -f -n 200 --namespace=noisy
LogNamespace=noisy
Sachant que sddm est un gestionnaire de session graphique, quel est le
rapport avec NFS, un partage de fichiers à travers le réseau ?
L'explication est dans la version longue... :)
***** Version longue *****:
J'ai plusieurs machines sur mon LAN, et seule une seule posait ce
problème (ie: "server").
Ce n'était pas lié qu'au disque SATA hot plug, car je pouvais reproduire
le problème tout aussi facilement avec une simple clé USB.
Pour ne rien simplifier, "Server" utilise un disque chiffré (LUKS +
LVM). Mais j'ai aussi un disque externe bootable, qui est chiffré avec
les mêmes technologies, et lui n'était pas affecté par ce problème.
Après pas mal de recherches, j'ai découvert l'existence du
"/proc/self/mountinfo"
La doc:
https://www.kernel.org/doc/Documentation/filesystems/proc.txt
Sur une machine "normale", j'ai cela:
# cat /proc/self/mountinfo
22 27 0:20 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
23 27 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:13 - proc proc rw
24 27 0:5 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev
rw,size=7972540k,nr_inodes=1993135,mode=755,inode64
25 24 0:22 / /dev/pts rw,nosuid,noexec,relatime shared:3 - devpts devpts
rw,gid=5,mode=620,ptmxmode=000
26 27 0:23 / /run rw,nosuid,nodev,noexec,relatime shared:5 - tmpfs tmpfs
rw,size=1600076k,mode=755,inode64
27 1 253:3 / / rw,noatime,nodiratime shared:1 - ext4
/dev/mapper/vga-root64 rw,errors=remount-ro,commit=300
[...]
Alors que sur "server", j'ai ceci:
# cat /proc/self/mountinfo
822 790 253:1 / / rw,noatime,nodiratime shared:343 master:1 - ext4
/dev/mapper/vgp-ROOT rw,discard,errors=remount-ro,commit=600
823 822 0:5 / /dev rw,nosuid,relatime shared:382 master:2 - devtmpfs
udev rw,size=16290564k,nr_inodes=4072641,mode=755,inode64
824 823 0:22 / /dev/pts rw,nosuid,noexec,relatime shared:383 master:3 -
devpts devpts rw,gid=5,mode=620,ptmxmode=000
825 823 0:24 / /dev/shm rw,nosuid,nodev shared:384 master:4 - tmpfs
tmpfs rw,inode64
[...]
La ligne principale qui pose problème est ici :
27 1 253:3 / / [...]
contre:
822 790 253:1 / / [...]
le 1er chiffre de chaque ligne est l'ID du point de montage du "/".
le 2nd chiffre est l'ID du parent de ce point de montage.
Ce qui saute aux yeux dans le cas de "server":
L'ID est spécialement élevé (822)
L'ID parent n'est pas "1", mais un autre chiffre très élevé (790).
Je ne retrouve ce comportement sur aucune autre de mes machines.
A partir de là, mon intuition s'est orienté sur toute la phase de boot :
initrd et systemd.
J'ai commencé à harmoniser la configuration de "server" avec celle du
disque externe bootable chiffré, mais sans résultat probant.
J'ai passé du temps à désosser l'initrd, pour finir par booter avec un
shell sh dans l'initrd (avant le montage du disque chiffré). Le
/proc/self/mountinfo était alors normal. Ce qui a donc rejeté le
problème plus loin dans la séquence de boot, à savoir systemd.
J'ai fini par booter avec le minimum de partitions (notamment sans le
/home et sans Xorg): Le /proc/self/mountinfo était là encore normal. Le
but était proche !!
A partir de là, j'ai constaté un truc surprenant :
- si je lisais le /proc/self/mountinfo en monde console (ctrl+alt+f1),
le contenu était normal
- par contre, si je le lisais depuis un terminal lancé depuis KDE, le
contenu était anormal (ID de montage trop important).
Donc le problème venait de sddm, le gestionnaire de session graphique.
Aussi, en passant à un autre gestionnaire de session graphique
(lightdm), le problème n'apparaissait plus.
Et là, j'ai fait le rapprochement avec une modification faite deux mois
plus tôt: le "LogNamespace=noisy" du "/etc/systemd/system/sddm.service"
Explication:
- Mon journalctrl est remplit de traces inutiles d'applications graphiques
- Une manière assez élégante de s'en défaire est de rediriger ces infos
vers une 2nd session de journalctrl, créé pour l'occasion (appelée
"noisy"), qui n'est stocké que dans petit buffer en mémoire
- Mais un effet non prévu de la manipulation est que cela fait une sorte
de re-montage du /, et que toutes les applications lancées sous sddm,
donc toutes applications graphiques ou commandes lancées depuis un
terminal graphique, n'ont plus accès au "/ originel".
D'où le :
822 790 253:1 / / [...]
Une fois retiré le "LogNamespace=noisy", et un redémarrage du sddm plus
tard, le /proc/self/mountinfo est de nouveau normal.
Et sans surprise, le partage NFS du disque non monté au démarrage
fonctionne de nouveau !
=> Problème corrigé !
Conclusion:
- Un problème complexe à corriger, et pas mal de doc lues, afin de
comprendre le phénomène
- Ce qui est surprenant, c'est que la simple activation du LogNamespace
ait autant d'impact
- Mais en fait, la lecture du "man 5 systemd.exec" est sans appel:
<extrait>
LogNamespace
[...]
Internally, journal namespaces are implemented through Linux mount
namespacing and over-mounting the directory that contains the relevant
AF_UNIX sockets used for logging in the unit's mount namespace. Since
mount namespaces are used this setting disconnects propagation of mounts
from the unit's processes to the host, similarly to how ReadOnlyPaths=
and similar settings describe above work. Journal namespaces may hence
not be used for services that need to establish mount points on the host.
</extrait>
- Cela m'apprendra à ne pas lire le man ... :)
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
