pam_systemd -> dbus-daemon -> systemd-logind -> dbus-daemon -> systemd
One could add more loops through dbus-daemon to make starting a dæmon at login even loopier, I suppose. (-:
It's interesting that @ska 's utmps would be a less circuitous way of achieving this. Because this is really just keying things off of insertions/deletions to an active logins table. One that has extra Desktop Bus compared to the original.
Lots of extra Desktop Bus.
@JdeBP utmp is not a good way to do *anything*; utmps was only written so utmp can at least work and content software that relies on it without security issues.
But yes, the systemd (but more generally, desktop) tendency to use D-Bus for *all the IPCs* is a clear indication that they favor uniformity over technical quality. They have a hammer, so software better present nail-like interfaces. Unix domain sockets would be much simpler, more efficient, and easier to maintain than going through D-Bus in most cases.
One can get possibly simpler still.
I got here because all of the noise and delay that pam_systemd.so makes on a modern #Debian system. And gvim.
gvim pausing for up to 25 seconds waiting for #DesktopBus services; and pam_systemd doing the same at login.
Some background:
[Continued…] #nosh
[…Continued]
If one has #DesktopBus running for any reason, that PAM module auto-starts systemd-logind, which in turn then attempts to auto-start systemd, then telling systemd to start a [email protected], which runs another instance of systemd as user 1000, which in turn runs another Desktop Bus dæmon, which in turn runs the GNOME dæmons that vim.gtk demand-starts.
And all of these are strongly coupled.
There are several ways to deal with this:
[…Continued]
1. Have a shim org.freedesktop.systemd1 that simply runs "service user@1000 start" or whatever.
But that involves having #DesktopBus as an integral part of the system, causes yet more Desktop Bus Death Rattle, and suffers from a lot of stuff now believing that there's an org.freedesktop.systemd1 service, with all of the wide range of *other* stuff that is coupled in with that. The strong coupling creates a huge cost.
Not a good idea.
So on to:
[…Continued]
2. Live with the noise, and make the login program directly run "service user@1000 start" or whatever. It's not a good idea to expand login in this way, especially after going to the effort of splitting login up into chain-loadable parts. It seems like a retrograde step.
3. Live with the noise, and remember that pam_exec.so exists. This is a least preferential not-entirely-bad idea.
But one can do better:
[Continued…] #Debian #DesktopBus #nosh
[…Continued]
4. Live with the noise, and realize that much of what systemd-logind is maintaining under /run/sytemd/{seats,users,sessions} is just a replacement login database, with one record per file, no machine-readable tables, and the records containing human-readable data that has to be parsed, prefixed with a comment saying that the files must not be parsed.
(They mean by other than systemd, which does lots of parsing at runtime.)
At which point:
[Continued…] #Debian #DesktopBus #nosh
[…Continued]
The parallels to #utmps now show up, because that's also effectively a hook into login (except through libc rather than PAM) that talks to a server via IPC to maintain a login database, just one that doesn't couple to a whole shedload of extra stuff, or use #DesktopBus.
Whilst utmps is alright, I still think that kernels should just provide access to the session tables that they already maintain.
Moreover:
[…Continued]
#FreeBSD, #NetBSD, and #OpenBSD still directly maintain actual utmpx files
Once one realizes that instead of looking at this as login running stuff one can regard it as effectively UPSERT/DELETE triggers on the active logins table, that need not be enacted by login at all, the most currently BSD-ish way of doing this presents itself: a kqueue() EVFILT_VNODE watch on utmpx/utx.active and some way of detecting what the diffs are.
[Continued…] #Debian #DesktopBus #nosh
[…Continued]
This could run as a standalone dæmon, entirely severable from everything else.
It only needs to watch for triggers, calculate the diffs (because with these flat file databases we still have to do some of the lifting that a more complex database would do) and fork off a "system-control start user@1000" or a "system-control stop user@1000" whenever appropriate.
It wouldn't even need to run as the superuser.
As a matter of fact:
[Continued…] #Debian #DesktopBus #nosh
[…Continued]
Something just like ttylogin-starter. Simply kqueue()-watching a different thing.
I already use this design, for a different mechanism that is coupled into systemd-logind, and it works well on #Debian (and does nothing on the BSDs).
http://jdebp.info/Softwares/nosh/guide/commands/ttylogin-starter.xml
[Continued…] #DesktopBus #nosh
[…Continued]
This is the Desktop Bus Death Rattle, by the way.
JdeBP
Laurent Bercot
navi
Lennart Poettering