Journal Où systemd résout des problèmes de cifs

Posté par . Licence CC by-sa
Tags :
26
24
sept.
2014

Cher journal,

Je voudrais partager avec toi le fruit d'une récente victoire sur une épine qui perforait mon pied depuis longtemps.

La petite histoire

Comme beaucoup de gens, j'accède à quantité de données stockées sur le réseau via le protocole CIFS. Peu enclin à la répétition de commandes mount à rallonge, j'avais choisi de renseigner mon fichier /etc/fstab avec les points de montage désirés.

Cependant, sur mes machines transportables, j'ai découvert que passer en mode veille avec un partage réseau monté pour se réveiller sur un nouveau réseau n'ayant plus accès au dit partage causait d'ennuyeux bugs.

Tout processus qui tentait d'accéder au point de montage du disque partagé se retrouve bloqué pendant un important laps de temps. Après d'infructueuses recherches quand à une solution à ce problème, je tente de le contourner via les fonctionnalités d'automount de systemd. Sans succès hélas.

Mais hier, une nouvelle tentative a fonctionné. L'automount n'était qu'une solution partielle à mon problème, il me fallait également démonter automatiquement ces partages réseaux lors de la mise en veille de mon ordinateur. Quelques minutes de lecture de man systemd.special m'ont fourni une réponse très simple: en ajoutant Conflicts=sleep.target à mes unités de mount, systemd s'occuperait tout seul du démontage lorsque nécessaire. Après quelques tests, je peux confirmer que tout fonctionne parfaitement, et j'en suis très heureux.

Le code pour les admins pressés

Voici donc les configurations nécessaires:

Fichier /etc/systemd/system/mnt-mydrive.mount

[Unit]
Description=Mount of network drive
Requires=network.target
Conflicts=sleep.target

[Mount]
Where=/mnt/mydrive
What=//my-drive-address/my-share-name
Options=uid=1000,user=username,password=*****
Type=cifs
TimeoutSec=5s

[Install]
WantedBy=multi-user.target

Fichier /etc/systemd/system/mnt-mydrive.automount

[Unit]
Description=Automount of network drive
Requires=network.target

[Automount]
Where=/mnt/mydrive
[Install]
WantedBy=multi-user.target

On installe les services et on les démarre:

systemctl daemon-reload

systemctl enable mnt-mydrive.mount mnt-mydrive.automount

systemctl start mnt-mydrive.automount

Ensuite, un ls /mnt/mydrive monte le disque réseau, et une mise en veille (ou veille prolongée) le démonte.

  • # Et systemd permet tout ça

    Posté par . Évalué à -10.

    Alors il n'y a plus de doute, systemd est bien le mal

    Dire que vous vous n'en avez rien à faire de la vie privée parce que vous n'avez rien à cacher, c'est comme dire que vous n'en avez rien à faire de la liberté d'expression parce que vous n'avez rien à dire. Edward Snowden

  • # Whaou

    Posté par (page perso) . Évalué à 5.

    Et quelle est la plus-value majeure par rapport à sleep.sh

    #! /bin/sh
    
    umount /mnt/mydrive
    pm-suspend # ou autre commande qui va bien
    

    On peut probablement même faire un truc un poil plus intelligent avec mount | grep (nfs|cifs) pour umount ensuite l'ensemble des trucs remotes.

    • [^] # Re: Whaou

      Posté par . Évalué à 0.

      Et quelle est la plus-value majeure par rapport à sleep.sh

      pouvoir dire que powershell systemd c'est mieux que les scripts bash tous moisis de ces vieux croulants réactionnaires qui sont restés à leur Unix/Linux d'antan.

    • [^] # Re: Whaou

      Posté par (page perso) . Évalué à 10.

      A vue de nez, l'intégration. Cad que je mets mon pc en veille en fermant le capot, ça le fera tout seul.

      Bien sur, si systemd l'a fait, alors tu peux le faire aussi en refaisant ce qu'il fait, cad en écoutant les événements en lançant ton truc suite à ça.

      • [^] # Re: Whaou

        Posté par (page perso) . Évalué à 10. Dernière modification le 25/09/14 à 00:10.

        Je n'ai pas fait la partie intégration, parce que ça dépend du système justement, mais bon, comme dit plus bas, il suffit d'appeller ledit script dans /etc/pm/sleep.d sous certaines distrib, /etc/powerd/scripts/lid_switch sous NetBSD, /etc/apm/suspend sous OpenBSD, …

        Pour moi, ça ressemble plus au final, regardez systemd c'est génial, quand on lit la doc, on trouve des trucs :) Le man de pm-suspend mentionne clairement /etc/pm/sleep.d et le comportement exécuté.

        • [^] # Re: Whaou

          Posté par (page perso) . Évalué à 3.

          bah, vu de loin je dirai tout de même qu'un fichier de configuration incluant "Description=Automount of network drive" vaut mieux qu'un script à lier depuis un sleep.d

          • [^] # Re: Whaou

            Posté par (page perso) . Évalué à 10.

            Déjà, il faut noter qu'il y'a 2 units, que le umount est impliqué par une commande un peu tricky (le Conflict), …

            Personnellement, si je dois répondre à la question, que se passe-t'il lors que je suspend ma machine, je préfére largement l'approche /etc/pm/sleep.d et les outils standards (cat /etc/pm/sleep.d/* et tu verra tout ce qui est executé dans l'ordre) que l'approche systemd (où il faut chercher les units requiered par sleep et celles qui sont en conflits, + tous les autres trucs que je connais pas encore sur systemd). Après, il y'a peut être une commande magique propre à systemd pour avoir la liste des units (récursivement) liées d'une façon ou d'une autre à la target sleep et déterminer leurs actions.

        • [^] # Re: Whaou

          Posté par . Évalué à 6.

          J'ai surtout fait avec l'outil que j'avais sous la main, sur la plupart des distros on trouve systemd, autant apprendre à s'en servir.

          Par contre je ne connaissais pas /etc/pm/sleep.d, ça devrait me permettre de résoudre ce problème sur mon ubuntu, merci.

          • [^] # Re: Whaou

            Posté par (page perso) . Évalué à 9.

            J'ai surtout fait avec l'outil que j'avais sous la main, sur la plupart des distros on trouve systemd, autant apprendre à s'en servir.

            Pas de souci. Mon souci principal vient du titre et du pseudo-FUD autour de ça, genre on a l'impression que systemd résoult un problème franchement ingérable avant alors qu'il existait des solutions simples et fonctionnels à ces questions (et reposant sur des outils standards)

    • [^] # Re: Whaou

      Posté par (page perso) . Évalué à 8.

      Et quelle est la plus-value majeure par rapport à sleep.sh

      Pour moi, la plus-value majeure, c'est qu'on retrouve les informations de montage et démontage au même endroit (/etc/systemd/*). Le jour où tu dois débugger ce genre de situation, c'est vachement plus pratique que de parcourir le système pour savoir ce qui provoque le comportement.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Commentaire supprimé

    Posté par . Évalué à 10.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: pm-action ?

      Posté par (page perso) . Évalué à 10.

      Génial!!!

      pm-utils, c'est un tas de gros hacks (et le projet est défini comme ça chez archlinux) pour contourner les bugs que suspend/hibernate provoque dans certains programmes…

      systemd propose lui à l'auteur du programme de gérer le problème directement dans la configuration de l'init, de le distribuer avec le code source et d'avoir une solution propre pour toutes les distribs…

      Tu vois la différence?

      Tu rajoutes à ça que pm-utils n'est plus codé depuis 2010… Et qu'il fait beaucoup plus qu'il ne devrait faire, c'est pas pour rien qu'il entre en conflit avec tlp.

      Effectivement, ça fait rêver ta solution…

      • [^] # Re: pm-action ?

        Posté par . Évalué à 7.

        Et qu'il fait beaucoup plus qu'il ne devrait faire

        Bah, comme systemdd en fait.

        • [^] # Re: pm-action ?

          Posté par (page perso) . Évalué à 7.

          Oui, mais toi, tu ne sais pas faire la différence entre un bon logiciel qui fait trop de choses et un mauvais logiciel qui fait trop de choses :)

  • # Conflicts=sleep.target

    Posté par . Évalué à 8.

    Ça sent le workaround fragile.
    Conflicts est utilisé ici pour une chose dont il n'est pas fait à la base.
    Pour Systemd qui se veut intégration au poil, bootage toujours plusse vite, etc,… Ne pas avoir prévu la gestion de la mise en veille/hibernation pour les points de montage, ça fait fausse note.

    Non je ne suis pas un anti-systemd mais son vocabulaire ne m'attire que très peu.

    • [^] # Re: Conflicts=sleep.target

      Posté par . Évalué à 2.

      Ça sent le workaround fragile.
      Conflicts est utilisé ici pour une chose dont il n'est pas fait à la base.

      J'ai eu cette impression également en écrivant mes unit, mais je n'ai pas l'impression que ça va poser des problèmes.

      Ne pas avoir prévu la gestion de la mise en veille/hibernation pour les points de montage, ça fait fausse note.

      Je trouve que ça laisse le choix. Certains points de montage n'ont pas de raison de bouger lors d'une mise en veille (disques locaux), d'autres si.

    • [^] # Re: Conflicts=sleep.target

      Posté par . Évalué à 8. Dernière modification le 25/09/14 à 09:57.

      Conflicts est utilisé ici pour une chose dont il n'est pas fait à la base.

      Je trouve au contraire que c'est utilisé de manière cohérente et logique : Conflicts sert à désactiver une unité lors de l'appel d'une autre unité, et c'est exactement ce qui se passe.

      Comme quoi c'est affaire de sensibilité (mais perso j'utilise plutôt autofs et NFS, et je n'ai jamais de souci avec la mise en veille).

      Ne pas avoir prévu la gestion de la mise en veille/hibernation pour les points de montage, ça fait fausse note.

      Pourquoi, quelqu'un l'avait prévu avant systemd ? Si on devait compter les fausses notes précédent systemd, on n'aurait pas fini…

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Conflicts=sleep.target

        Posté par . Évalué à 3.

        Comme quoi c'est affaire de sensibilité (mais perso j'utilise plutôt autofs et NFS, et je n'ai jamais de souci avec la mise en veille).

        Effectivement, je me relis et moi même j'arrive à trouver ma tournure de phrase initiale un poil ambigüe. Je peux donc avoir perdu quelques points de crédibilité sur la critique sémantique :p. La mise en veille n'est effectivement pas problématique, seulement, elle devrait gérer de manière plus cohérente et robuste les ressources qui pourraient êtres bloquantes. "Conflict" devrait notamment être remplacé par un mot clé particulier à la mise en veille.

        Ne pas avoir prévu la gestion de la mise en veille/hibernation pour les points de montage, ça fait fausse note.
        

        Pourquoi, quelqu'un l'avait prévu avant systemd ? Si on devait compter les fausses notes précédent systemd, on n'aurait pas fini…

        Ben quitte à améliorer un système afin de le rendre plus automatique possible et palier aux défauts d'un gnu/linux pas assez "plug-n-play" pour un usage desktop/mobile, la gestion d'accès aux ressources distants est quand même une problématique non négligeable. Que le niveau de complexité introduit par systemd soit contre-balancée par un réel apport de confort.

        Après, ce n'est pas juste pour basher, je vais apprendre à vivre avec systemd.

    • [^] # Re: Conflicts=sleep.target

      Posté par (page perso) . Évalué à 8.

      Ne pas avoir prévu la gestion de la mise en veille/hibernation
      pour les points de montage, ça fait fausse note.

      En fait, c'est pas la mise en veille le souci, c'est le changement et ou la perte de la connectivité. La mise en veille est juste un déclencheur. Je peux par exemple avoir un point de montage non réseau qui continue de marcher ou qui va dépendre du fait que je retire un cable pendant que le pc est en veille. Ou mettre en veille et revenir dans le même réseau de façon transparente.

      Intuitivement, je me dit que ça devrait être fait au niveau du filesystem, mais peut être que les sémantiques et que le code ne permet pas de faire ça de façon optimum.

  • # idem

    Posté par (page perso) . Évalué à 3.

    passer en mode veille avec un partage réseau monté pour se réveiller sur un nouveau réseau n'ayant plus accès au dit partage causait d'ennuyeux bugs.

    ah oui, je ne suis pas le seul à être tombé sur ce point bloquant ?
    ça m'a bien plombé 2h, alors qu'il suffisait de modifier fstab, le message étant peu explicite…
    Enfin un point à charge de systemd (outre le /usr/bin et /bin fusionnés), sinon systemd n'a pas changé ma vie, je souhaiterais simplement que mon système démarre (vite éventuellement).

    • [^] # Re: idem

      Posté par . Évalué à 3.

      A te lire je n'ai pas l'impression qu'on ait exactement le même soucis, moi ça posait surtout des problèmes à KDE, dont le sélectionneur de fichiers devenait gelé, là où j'ai l'impression que toi c'est carrément la sorti de veille où le démarrage qui se passe mal.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.