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

dbus as user service

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?

Re: dbus as user service

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

Re: dbus as user service

Reply #3 –
@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.

Re: dbus as user service

Reply #4 –
@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.  

Code: [Select]
$ 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
Code: [Select]
$ 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)

Re: dbus as user service

Reply #5 –
Quote from: vaapicon – on
@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



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

Re: dbus as user service

Reply #6 –
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.
 

Re: dbus as user service

Reply #7 –
Quote from: artoo – on

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

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:
Code: [Select]
  --enable-user-session   enable user-session semantics for session bus under
                          systemd

Re: dbus as user service

Reply #8 –
Quote from: davmac – on
The configure option name is highly misleading!



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.

Re: dbus as user service

Reply #9 –
Quote from: artoo – on
The dbus user session only works with systemd, hence it is disabled.
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:

Code: [Select]
       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"?

Quote
Consequently, dbus user sessions will not work on artix.
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?

Re: dbus as user service

Reply #10 –
Quote from: high1 – on
If I don't start dbus like this, and instead let Gnome start it, groups work fine. Am I missing something obvious?
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.

Re: dbus as user service

Reply #11 –
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.

Re: dbus as user service

Reply #12 –
@davmac, are you the developer for dinit?

Re: dbus as user service

Reply #13 –
@vaapicon yes.

Re: dbus as user service

Reply #14 –
@davmac  Good Stuff! May we never have to type systemctl again.