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.targetFichier /etc/systemd/system/mnt-mydrive.automount
[Unit]
Description=Automount of network drive
Requires=network.target
[Automount]
Where=/mnt/mydrive
[Install]
WantedBy=multi-user.targetOn 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 alendroi . É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 zul (site web personnel) . Évalué à 5.
Et quelle est la plus-value majeure par rapport à sleep.sh
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 zurvan . Évalué à 0.
pouvoir dire que
powershellsystemd c'est mieux que les scripts bash tous moisis de ces vieux croulants réactionnaires qui sont restés à leur Unix/Linux d'antan.« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Whaou
Posté par Misc (site web personnel) . É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 zul (site web personnel) . Évalué à 10. Dernière modification le 25 septembre 2014 à 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 saltimbanque (site web personnel) . É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 zul (site web personnel) . É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 Shuba . É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 zul (site web personnel) . Évalué à 9.
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 claudex . Évalué à 8.
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 Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pm-action ?
Posté par gnumdk (site web personnel) . É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 totof2000 . Évalué à 7.
Bah, comme systemdd en fait.
[^] # Re: pm-action ?
Posté par zul (site web personnel) . É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 Le Gab . É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 Shuba . Évalué à 2.
J'ai eu cette impression également en écrivant mes unit, mais je n'ai pas l'impression que ça va poser des problèmes.
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 zebra3 . Évalué à 8. Dernière modification le 25 septembre 2014 à 09:57.
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).
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 Le Gab . Évalué à 3.
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.
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 Misc (site web personnel) . Évalué à 8.
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 BAud (site web personnel) . Évalué à 3.
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 Shuba . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.