JdeBPThe 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.
JdeBP (@[email protected])
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
JdeBP@oneguynick @grahamperrin @karinjiri
That really does not sound "resolved" as has been marked.
The bug report makes it sound like a problem where something is not behaving correctly when there is no systemd-logind on the Desktop Bus.
Which means that whomever this affects has to sit down and trace what is happening across the system-wide Desktop Bus with both the output of dbus-monitor --system and the log output of the system-wide dbus-daemon wherever that is going to.
And at the very least ktrace the processes that die.
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.
The challenge will be finding out whence the Desktop Bus service definition for org.bluez.obex is installed on your operating system.
/usr/local/share/dbus-1/services or /usr/share/dbus-1/services is the starting point.
"Helpfully", the Desktop Bus service file does not have to be named anything appropriate, but just has to have Name=org.bluez.obex in the file itself.
Equally helpfully, Debian et al. have decided that *next* name that you get to look up is not dbus-org.bluez.obex.service , but Debian's own (long-standing) name for this.
https://sources.debian.org/src/bluez/5.82-1.1/debian/patches/org.bluez.obex.service.in.patch
It's trying and failing to "D-Bus activate" a Desktop Bus service named org.bluez.obex.
#DesktopBus bus activation is not a good thing. For starters, you now get to poke around in your dbus-1 tree to find out whether there's a Desktop Bus service file for that name.
Here's how it actually works when one is using my service manager:
http://jdebp.info/Softwares/nosh/guide/per-user-dbus-demand-start.html
systemd actually got to put hooks into Desktop Bus, but the same essentials happen. The bus broker finds a DBus service definition, and that then points to an actual service manager's separate service definition.
http://jdebp.info/Softwares/nosh/avoid-dbus-bus-activation.html
The challenge will be finding out whence the Desktop Bus service definition for org.bluez.obex is installed on your operating system. And installing it if it is missing.
Only some operating systems let one search for packages by what files they install.
[…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: