Artix Linux Forum

I'm a little out of my depth here, so I would appreciate if someone can help - I've used https://github.com/XynonWasTaken/dinit-userservd for user services managed with dinit, and dinit is also system level.
I've created services for syncthing, dbus and pipewire - pipewire needs dbus to be able to start. And while everything works - when I start dbus through user service, I've noticed that groups command is not returning other groups that my user is in - so instead of wheel high1, it just returns high1. Dbus service looks like this:
type = process
command = /usr/bin/dbus-daemon --session --nofork --nopidfile  --print-address 1 --address $XDG_RUNTIME_DIR/bus
load-options = sub-vars
ready-notification = pipefd:1
If I don't start dbus like this, and instead let Gnome start it, groups work fine. Am I missing something obvious?

https://github.com/XynonWasTaken/dinit-userservd-services/tree/main/services

Dbus user session are not supported by elogind, ie only available with systemd due to tight integration voodoo with dbus.

@cat herders of linux , I've tested Xynons service definitions, those have the same issue as the one I described. So, @artoo, this is actually expected? I mean, groups command is pulling info from dbus session? The weird thing is that if I let gnome spawn a dbus session itself, it works properly.

@artoo , Im confused when you say "Dbus user session are not supported by elogind". It appears as if the dbus user session I start is working with elogind running. Is it really not working right in some way
 
I dont use dinit-userservd, and elogind is running, but I do start a dbus session with dinit. My whole graphical session is started with dinit. Everything subsequently started has dinit as the parent process and terminates nicely with "dinitctl  shutdown". No lingering dbus started processes. No missing groups with the groups command.  

$ dinitctl list
[[+]     ] boot
[{+}     ] swaywm
[{+}     ] sway 32006
[{+}     ] dbus 32003
[{+}     ] wlsunset 32072
[{+}     ] nm-applet 32071
[{+}     ] audio
[{+}     ] pipewire 32070
[{+}     ] wireplumber 32075
[{+}     ] pipewire-pulse 32076
[{+}     ] blueman 32069
[{+}     ] polkit 32068
[{+}     ] mako 32067

$ pstree -Tp $(ps -C dinit -o pid=)
dinit(32000)─┬─at-spi-bus-laun(32123)───dbus-daemon(32128)
             ├─at-spi2-registr(32134)
             ├─blueman-applet(32069)
             ├─blueman-tray(32165)
             ├─dbus-daemon(32003)
             ├─foot(32219)───zsh(32220)───pstree(32263)
             ├─gvfsd(32097)
             ├─gvfsd-fuse(32113)
             ├─mako(32067)
             ├─nm-applet(32071)
             ├─obexd(32155)
             ├─pipewire(32070)
             ├─pipewire-pulse(32076)
             ├─polkit-gnome-au(32068)
             ├─sway(32006)
             ├─swaybg(32047)
             ├─swayidle(32060)
             ├─waybar(32054)
             ├─wireplumber(32075)
             ├─wl-paste(32056)
             ├─wl-paste(32058)
             └─wlsunset(32072)

Whatever your setup,. dbus user sessions can't simply work, because it is disabled in dbus.

Do not confuse placing a service in your user home to qualify as a "user service".

https://gitea.artixlinux.org/packagesD/dbus/src/branch/master/trunk/PKGBUILD#L51

Is user dbus session disabled, because it was inherited from the arch package? I think they disable user sessions, because they rely on systemd socket activation. I guess it should be OK to allow dbus session on user level.

I think you're confused yourself. My understanding is that "--disable-user-session" disables user session semantics when dbus-daemon is used with systemd, which is not the case for Artix, of course. A "user session" of dbus is just an in instance which listens on a different socket and uses a different location for service directories. The dbus-daemon --session option enables this mode, and doesn't require that it be built with systemd support nor with --enable-user-session. The configure option name is highly misleading!

From the configure --help output:

  --enable-user-session   enable user-session semantics for session bus under
                          systemd

Yes, and no, I am not confused.
The dbus user session only works with systemd, hence it is disabled.
Elogind does not support user dbus.
Consequently, dbus user sessions will not work on artix.

Then what is it that dbus-daemon --session actually does?

Edit: or similarly, dbus-launch (which runs dbus-daemon --session). The manual page for which:

       The dbus-launch command is used to start a session bus instance of
       dbus-daemon from a shell script. It would normally be called from a
       user's login scripts.

Are you saying that a dbus "session instance", run by a user, is not the same as a "dbus user session"?

The system I'm typing on currently doesn't happen to be running Artix, but it's not running systemd either, and yet I have a dbus user session running. At least, I have a dbus-daemon instance that is running separately to the system instance, under my own user id, and with clients connecting to it. Is that not a dbus user session?

Looking quickly at the dinit-userservd code, I can see that it uses only the uid and gid of the user when launching the dinit user instance. So, it's not setting any of the supplementary groups. Anything run underneath it will be missing those groups as well, I'm afraid. You could try opening an issue against dinit-userservd.

Thanks, @davmac , will do so.
@artoo, If I don't start a dbus session, Gnome will start one by itself just fine. If I start one using dinit-userservd, it happily uses that one. And both of those are ran as user services ( a monitored process started with current user privileges ) - so I don't think that dbus user session works only with systemd.

@davmac, are you the developer for dinit?

@vaapicon yes.

@davmac  Good Stuff! May we never have to type systemctl again.

I've reported the issue https://github.com/chimera-linux/dinit-userservd/issues/2. It should be resolved once dinit in artix is updated, along with dinit-userservd. Thanks for the guidance, @davmac.

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?

Thanks, I'm glad you find it useful :)

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

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


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).

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.