[opensuse] Catch 22 with systemd, fstab and boot/shutdown
My setup is a laptop on a home network, accessing a server/desktop. I could well have mucked up fstab, I don't know, but ... When I originally set the laptop up, things were reasonably fine, except the CD-Rom wouldn't mount automatically, or if it did then if there wasn't a CD-Rom in the drive systemd would fall over at boot. Then I discovered that if Windows suspended, fstab couldn't mount the windows drive, and again systemd fell over at boot. Then I added my network drives, and discovered that, because it's a laptop with the wifi password stored in my user configuration, that boot hung for a couple of minutes trying to mount them until it timed out and allowed the boot to resume. Looking on the web, I discovered that apparently putting the correct options in fstab is the proper way of mounting partitions (I couldn't find any documentation specifically about creating disk service files). So I did that, and now I gather systemd creates temporary service files for me. Great, except that when I shut down the system my user is logged out, the network dies, and the unmounts seem to hang forever. I can't remember if they have ever successfully timed out and let the laptop shut down - certainly displaying the shutdown the umount command has been running for over 15 minutes. So basically, the question is "how do I make systemd do the mounts and unmounts in the right order, WHILE THE USER IS LOGGED IN, and not hang starting or stopping the system because the network is not available?" Everything I've tried so far (as you can see) has simply moved the problem somewhere else. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-24 02:23, Wols Lists wrote:
My setup is a laptop on a home network, accessing a server/desktop. I could well have mucked up fstab, I don't know, but ...
When I originally set the laptop up, things were reasonably fine, except the CD-Rom wouldn't mount automatically, or if it did then if there wasn't a CD-Rom in the drive systemd would fall over at boot.
Then I discovered that if Windows suspended, fstab couldn't mount the windows drive, and again systemd fell over at boot.
You have to use the option "nofail".
So I did that, and now I gather systemd creates temporary service files for me. Great, except that when I shut down the system my user is logged out, the network dies, and the unmounts seem to hang forever. I can't remember if they have ever successfully timed out and let the laptop shut down - certainly displaying the shutdown the umount command has been running for over 15 minutes.
I believe this is a know bug. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhdzygACgkQja8UbcUWM1wGCAD/SuOZAYU+XLLHMt+EKkjjhMxt g5l5eMCN+lrj8nbShPsA/RPAnteBNvtA1YX5k5ikfm3kkI0/2clLBRFrT4g49d2n =0Nz0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
24.12.2016 04:23, Wols Lists пишет:
So basically, the question is "how do I make systemd do the mounts and unmounts in the right order, WHILE THE USER IS LOGGED IN, and not hang starting or stopping the system because the network is not available?"
I am afraid there is currently no way to do it. You would need to order your mount units against user session(s) so that mount units are stopped before user sessions. But user sessions are dynamic so you cannot add this dependency to mount units; and user sessions do not utilize templates, but created internally, so you cannot add these dependencies to sessions either. This would require adding some synchronization point and order all user sessions before it, so that you could add your mount units against this synchronization point. Something that requires source code change. Try to open systemd issue on github. Pragmatic answer - if your mount points depend on existence of user session, why not perform mounting and unmounting as part of user session? You can write polkit or sudo rules to allow your user unrestricted access to specific mount points. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/24/2016 02:42 AM, Andrei Borzenkov wrote:
I am afraid there is currently no way to do it. You would need to order your mount units against user session(s) so that mount units are stopped before user sessions.
Indeed. Its a strange type of dependency. That why we have "pam_mount" to do the mount/unmount when a user logs in or out. Those file systems won't be in the normal fstab derived group. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/23/2016 08:23 PM, Wols Lists wrote:
Looking on the web, I discovered that apparently putting the correct options in fstab is the proper way of mounting partitions (I couldn't find any documentation specifically about creating disk service files).
So I did that, and now I gather systemd creates temporary service files for me. Great, except that when I shut down the system my user is logged out, the network dies, and the unmounts seem to hang forever. I can't remember if they have ever successfully timed out and let the laptop shut down - certainly displaying the shutdown the umount command has been running for over 15 minutes.
This is an incomplete answer. First: forget about fstab altogether. You may want to delete it. Under systemd there is a backward compatable function called a 'generator' that scan /etc/fstab and build the unit files that systemd actually uses. This is why altering fstab on a running system makes no difference. However if you remove the pertinent entries from fstab or delete fstab altogether and set up your own corresponding unit files under /et/systemd/ then you CAN have control over the order. What do these look like? well you can get tempaltes by seeing what the generator produces by looking in /run/systemd/generator/ and look at the *.mount files. You will see in those units that there are "Before:" and "After:" lines. Right now the "After:" just deals with doing the fsck first :-) But if I want to mount "/home/anton/MyDocuments/Letters/Family" ... And I have file systems for HOME, MYDOCUMENTS, LETTERS I need to make sure they are mounted in the right order, and that's where I can make use of the "After:" clauses. Now systemd has some smarts when it comes to mounting file systems, but those smarts may not suit your use case, so the customized Dot-Mount files can force it to follow the order that applies for your use case. I realise this is an incomplete answer. It doesn't answer tour needs for the interaction with the user login. I haven't drilled down to understand the logind function yes. I am aware that PAM can be used to mount a file system when a user logs in, unmount when the user logs out -- see "man pam_mount". That is old hat; dates back to the SUN thin workstations with NFS. Please see the PAM documentation for that. You solution might lie there. I see also that 'loginctl' lets you attach specific devices to logged in users. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/24/2016 05:24 AM, Anton Aylward wrote:
This is an incomplete answer.
First: forget about fstab altogether. You may want to delete it.
Well that was @5 in the morning; now after a couple of pints of coffee it occurs to me that there is another approach. We normally think of systemd as a SYSTEM level function starting all those daemons and services at boot time, restarting when necessary etc etc. The reality is that there are instances of it for each user, private to the user as well. We don't seem to discuss those very much, do we? But they are there. Run 'ps' and grep for you own ID and you'll see a "/usr/lib/systemd/systemd --user" Hmm. You'll also see a "(sd_pam)" which seems an odd way to express a process, but that's anther matter and it relates to the use of PAM I mentioned before. It is also a fork of systems but its there soly to clean up whatever PAM setup after the user exits. But systemd in user mode is something else. q.v. the man pages. In essence, this per-user systemd users the ability to manage services under the user's control. Users can start, stop, enable, and disable their own units. So you can set up units for the filesystems you want mounted (and unmounted) when the user logs in (and out) in the user's ~/systemd/ directory. One might even arrange that the X system, the whole GUI, only comes up when a certain user logs in. That is, X11 is a user process not a system process. The same might go for many other services as well that are pointless unless the user is logged in, fetchmail, dovecot perhaps even the SMB services that would allow the user to access a Windows of CIFS file server. This is, naturally, a PAM service -- see /etc/pam.d/systemd-user Just as system units have a 'search path", so too do user units. they are lcoated are located in the following directories, ordered precedence: * /usr/lib/systemd/user/ where units provided by installed packages belong. * ~/.local/share/systemd/user/ where units of packages that have been installed in the home directory belong. * /etc/systemd/user/ where system-wide user units are placed by the system administrator. * ~/.config/systemd/user/ where the user puts its own units. When systemd user instance starts, it brings up the target default.target, just like with the system :-) Other units can be controlled manually with systemctl --user. Of course to make use of this you need to know how to (a) write custom units and (b) stop the system generators doing it first. What I wrote previously about disabling the relevant lines in /etc/fstab so that the Generator doesn't build the Dot-Mount unit files for the file systems you want custom control over still applies. Please note: What you get running at the command line and what gets automated this way will different in one important way.. At the CLI you have all of the BASH environment, your PATH, DISPLAY and many other settings. Systemd does not make use of BASH, it execl()s the commands directly and has its own ideas about variable expansion. There are ways to address all this but they take a bit of prior setup, for example, building things into ~/.pam_environment beforehand. You can also try using the "Environment=" declarations in a Dot-unit, but that hasn't proven too easy when I've tried it. There's supposed to be a global or global-per-user way .... *sigh* I hope this triggers some thoughts and leads to experimentation. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Wols Lists