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