Pete Zaitcev (zaitcev) wrote,
Pete Zaitcev

More system administration in the age of SystemD

I'm tinkering with OpenStack TripleO in a simulated environment. It uses a dedicated non-privileged user, "stack", which can do things such as list VMs with "virsh list". So, yesterday I stopped the undercloud VM, and went to sleep. Today, I want to restart it... but virsh says:

error: failed to connect to the hypervisor
error: Cannot create user runtime directory '/run/user/1000/libvirt': Permission denied

What seems to happen is that when one logs into the stack@ user over ssh, systemd-logind mounts that /run/user/UID thing, but if I log as zaitcev@ and then do "su - stack", this fails to occur.

I have no idea what to do about this. It's probably trivial for someone more knowledgeable to throw the right pam_systemd line into /etc/pam.d/su. But su-l includes system-auth, which invokes, and yet... Oh well.

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 



February 15 2018, 13:39:27 UTC 11 months ago Edited:  February 15 2018, 13:39:38 UTC

File a bug? (not that folks pushing that crap are exactly known for fixing things...)
Blast from the past, it sounds like this hundred-comments-worth bug:

Maybe try using “runuser” instead of “su”? It doesn't go through full PAM stack.

BTW, you got capitalisation wrong – it's “systemd”, all lowercase.
You mean you haven't noticed the constant log noise "pam_systemd(su:session): Cannot create session: Already occupied by a session" which these existing PAM configurations cause? :-P.

In general people wouldn't want `su -c` / `sudo` to be potentially spinning up a whole `systemd --user` instance... and shutting it down immediately afterwards.

There are commands other than `su` that _would_ do that. See It seems like if "stack" did use a systemd service inside `systemd --user`, then it would want that to "linger". See "loginctl enable-linger". Overall, perhaps this seems a baroque way of tricking libvirt to do what you want. But at least I'd suggest it's preferable to enabling lingering and not try to set up the same directory as logind does. I have not seen any standardized protocol for logind to share this responsibility with others :). It seems to risk it being torn down by logind when it thinks it's finished with. That might be what happened to you, I dunno.

In pam_systemd code there's something weird I don't understand. $XDG_RUNTIME_DIR is carefully supposed to not get set when switching user, except that code seems unreachable anyway because of the above error message. Anyway, what you *should* find with `su -` is that the env var is empty. `su` without `-` would of course pass through the env vars, in which case you'd end up with a very similar-looking error message to yours. It's the sort of thing that makes me wary of `su` without `-`.

In no case will pam_systemd as called by `su` or `sudo` set $XDG_RUNTIME_DIR to the target user's directory, or create it if it does not already exist. It does not sound like this particular combination of tools would work.

... except that tripleo-quickstart says it has a hack to paper over the problem of su v.s. $XDG_RUNTIME_DIR. I don't know what they're doing or exactly how it might have gone wrong. Only that if it can go wrong despite that you used `su - stack` which the docs told you to, I have suspicions they are not using the "correct" way to ensure it is created.