Le nombre de montages n'est pas réinitialisé après l'exécution automatique de fsck au démarrage
Il y a un PC sous Xubuntu 15.10 (astucieux). Le système est configuré pour exécuter fsck sur une partition lorsque cette partition est montée 20 fois. Après cela, le comportement attendu est que le nombre de montages doit être réinitialisé, mais ce n'est pas le cas. Cela signifie que, comme le nombre de montages dépasse 20, fsck s'exécute automatiquement à chaque démarrage du PC.
tune2fs indique que l'état du système de fichiers est propre et que smartctl ne montre aucun problème.
Contournements utilisés jusqu'à présent:
- Utilisez
tune2fs -Cpour réinitialiser le nombre de montages manuellement - Démarrez à partir d'un Live CD et exécutez fsck sur la partition. cela semble réinitialiser correctement le nombre de montages à la fin
Lorsque le nombre de montages atteint 20 la prochaine fois, le problème réapparaît: le nombre de montages n'est pas réinitialisé après l'exécution automatique de fsck.
J'ai effectué des recherches sur ce site et à d'autres endroits, mais je n'ai trouvé aucun indice quant à ce qui pourrait causer le problème. Des idées?
Merci d'avance.
Après un peu d'investigation, j'ai découvert que le problème venait du service systemd-fsckd du paquetage systemd. Au moment de la rédaction de cet article, les versions disponibles dans wily et xenial semblent contenir le code incriminé (225-1ubuntu9 et 229-4ubuntu4 respectivement).
Solution
Comme le service n'est pas nécessaire au bon fonctionnement du système, une solution simple consiste à le désactiver en exécutant la commande suivante:
systemctl mask systemd-fsckd.service systemd-fsckd.socket
L'inconvénient est que maintenant Plymouth ne rendra pas compte des progrès de fsck. En fait, cela n'indique même pas à l'utilisateur qu'une vérification du système de fichiers est en cours.
Explication
Un peu d’arrière-plan de la page man du service :
systemd-fsckd.service est un service responsable de la réception de la progression de la vérification du système de fichiers et de la communication de certaines données consolidées à la console et à plymouth (le cas échéant). Il gère également les annulations de chèques possibles.
systemd-fsckd reçoit des messages sur la progression de la vérification du système de fichiers de fsck via un UNIX domaine socket [...]
Le problème avec ce service est qu'il utilise un délai d'attente codé en dur de 30 secondes lors de l'exécution d'un epoll_wait sur le socket pour les informations de progression. Si fsck ne signale pas la progression en moins de 30 secondes, alors systemd-fsckd ferme le socket et quitte avec succès sans enregistrer quoi que ce soit aussi loin que je pouvais voir.
La prochaine fois que fsck écrit dans le socket (maintenant fermé) pour signaler l'avancement, il meurt avec un SIGPIPE. Comme fsck ne se termine jamais, le nombre de montages n'est pas réinitialisé à ce moment-là.