Skip to main content ↑ ↓
Topic: dbus as user service (Read 2287 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: dbus as user service

Reply #17 –
Quote from: artoo – on
https://packages.debian.org/sid/dbus-user-session

Worth a read.

Thanks, I think I understand the confusion now: a "user session" is a session associated with a user, regardless of how many individual logins they have, rather than being associated only with the login session. The connection with systemd is that systemd arranges the user session instance of the dbus daemon. I guess part of the issue in our discussion is terminology, i.e. there's a special meaning of "user session" (that's embodied in that Debian package description and in the dbus-daemon configure script, though not in any official documentation I could find) and that's what you're referring to (and fair enough).

However, this concept of dbus user session is exactly what dinit-userservd also enables - a single dbus-daemon instance associated with the user, regardless of how many individual logins they have - and that's exactly what this topic is discussing. While dbus may not provide the support for user sessions except via systemd, it's possible to arrange the exact same functionality without that support being present in dbus itself. So, wouldn't this qualify as a user session, or am I still not understanding you correctly?

Re: dbus as user service

Reply #19 –
Quote from: davmac – on
So, wouldn't this qualify as a user session, or am I still not understanding you correctly?


Whatever dinit does, I doubt very much it replicated the systemd dbus user session, because this would require (e)logind to be tied in somehow.

In short, it is doubtful dbus user session will work on artix without a session tracking supporting it, let alone implementing a common service wrapper that some consuming code usually calls with systemctl --user.
All init maintainers would have to agree if this was a thing.   :o

Re: dbus as user service

Reply #20 –
Quote from: artoo – on
Whatever dinit does, I doubt very much it replicated the systemd dbus user session, because this would require (e)logind to be tied in somehow.

Just to be clear, it's not actually dinit but dinit-userservd (which is separate software with a different author).

Quote
In short, it is doubtful dbus user session will work on artix without a session tracking supporting it, let alone implementing a common service wrapper that some consuming code usually calls with systemctl --user.

I guess what you're saying is that a "dbus user session" necessarily involves a setup where dbus-daemon talks to the systemd instance (or other manager implementing the same interface) in order to launch services that will provide bus names, rather than just launching the process itself, whereas I took "dbus user session" to mean what it linguistically means - a dbus instance running as part of a user session.

But, I understand now why you are saying that having a dbus user session isn't supported in Artix (I think). It's just that you posted to say that dbus user sessions aren't supported, which was taken to imply that the original poster was asking for something that wasn't supported, which was not the case. They were asking about how to run a user-associated dbus-daemon instance under a user instance of a service manager (dinit) via dinit-userservd, which is perfectly possible (and I think it's good to be clear about that).

Re: dbus as user service

Reply #21 –
This was fixed in dinit-userservd, this is the issue:
https://github.com/chimera-linux/dinit-userservd/issues/2.

I'm not sure what's not supported with dubs, but with this commit https://github.com/chimera-linux/dinit-userservd/commit/52ddb5049226a5917205b20561e30c82432ff8dc chery-picked, I had no issues running dbus as a user session which GNOME would pick up and happily use. I also needed the gpg-agent, and I was able to update the dbus session once the socket and the ssh socket initialize. So, for my purposes, it's working - and that means running a dbus session with user privileges to which a desktop connects to.