#desktopbus — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #desktopbus, aggregated by home.social.
-
The opposite is fun, too: when there's a system #DesktopBus broker running but it's not a systemd system, and logging in through a chain of intertwined mechanisms tries to auto-start #systemd.
-
hostnamectl gets its information across the #DesktopBus from hostnamed. And hostnamed in turn gets its information from reading the os-release file(s).
So when that someone has deleted your /etc/os-release (and /usr/lib/os-release and /run/os-release), you'll find that hostnamectl will not be able to give you the information. Because the information isn't there any more.
-
[…Continued]
This is the Desktop Bus Death Rattle, by the way.
-
[…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 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]
#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]
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]
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]
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]
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]
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]
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]
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]
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]
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:
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
<servicehelper> in a conf file and a launch helper have definitely worked, although I haven't re-tested in the past couple of years. My launch helper is just a script that knows how to invoke various commands such as initctl or system-control.
The irony, as explained on the FGA there, is that they could have made the #DesktopBus broker itself talk to multiple service managers and know what to do; had patches to do so not been blocked.
-
For best results, one has to turn off the Desktop Bus broker's own rubbish service launching and intercept and send all service launch attempts over to proper service management.
https://jdebp.uk/Softwares/nosh/guide/per-user-dbus-demand-start.html
https://jdebp.uk/Softwares/nosh/guide/commands/dbus-daemon-launch-helper.xml
https://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html