FS#63189 - systemd user actions not seen for user dbus

Attached to Project: Community Packages
Opened by Jonas DOREL (jdorel) - Sunday, 14 July 2019, 10:27 GMT
Last edited by Balló György (City-busz) - Monday, 02 September 2019, 08:10 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When monitoring the user dbus with `busctl --user monitor` in terminal A, and activating a user unit with `systemctl --user start <unit>` in terminal B, I cannot see anything in terminal A.

journalctl -eu indicates to me that that `busctl --user monitor` connects correctly:
```
Jul 14 11:46:37 notebook dbus-daemon[1013]: [session uid=1000 pid=1013] Connection :1.7007 (uid=1000 pid=11514 comm="busctl --user monitor ") became a monitor.
```

The dbus daemons are running: (result from ps -aux | grep dbus)
```
dbus 487 0.0 0.0 11532 1808 ? Ss Jul11 3:17 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
jdorel 1013 0.0 0.0 10908 1424 ? Ss Jul11 0:09 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
jdorel 1118 0.0 0.0 10512 908 ? S Jul11 0:02 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
```

Systemd is registered: (busctl --user | grep systemd)
```
busctl --user | grep systemd
:1.0 847 systemd jdorel :1.0 user@1000.service - -
org.freedesktop.DBus 847 systemd jdorel - user@1000.service - -
org.freedesktop.systemd1 847 systemd jdorel :1.0 user@1000.service - -
```

Environment:
Xorg + i3 started through zshrc

Context:
I am trying to monitor my user services, so that I can get notified when a service fails. I could use OnFailure= in my units, but I want to monitor my user services globally. To do that, I want to monitor DBus for system change (Member=UnitRemoved).

Additional info:
systemd 242 (242.32-3-arch)
This task depends upon

Closed by  Balló György (City-busz)
Monday, 02 September 2019, 08:10 GMT
Reason for closing:  Not a bug
Additional comments about closing:  You can ask help in our forum.
Comment by Dave Reisner (falconindy) - Sunday, 14 July 2019, 10:32 GMT
You have too many dbus daemons running. You should only have 2 (well, 1 system bus, plus another for each user), both launched by systemd.
Comment by Jonas DOREL (jdorel) - Sunday, 14 July 2019, 10:44 GMT
I looked into this, but the second user DBus daemon is launched by the `at-spi-dbus-bus` service, for accessibility, and is installed by `gtk3`. So it seems weird that it causes an error.
Comment by Dave Reisner (falconindy) - Sunday, 14 July 2019, 10:48 GMT
There's no error, you just have events split between session dbus instances. That's why you're "missing" some. You need to figure out how to avoid launching that other dbus session.
Comment by Jonas DOREL (jdorel) - Sunday, 14 July 2019, 11:03 GMT
I am not sure of this, but from what I see from the following, they both use the same address, so message sent to one should also appear on the other no ?

```
$ for pid in 1118 1013; do echo $(</proc/$pid/environ tr \\0 \\n | grep -E '^DBUS_SESSION_BUS_ADDRESS='); done
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
```
Comment by Dave Reisner (falconindy) - Sunday, 14 July 2019, 11:19 GMT
Sorry, I'm re-reading your original report and realizing that I misunderstood the premise. The multiple dbus instances is probably still something to fix, but it seems you're looking for something that you'll never see. 'systemctl' only communicates over dbus when there's an auth check required, i.e. when non-root uses the system manager instance. When the UID of the user matches the UID of the systemd instance, dbus isn't used. Instead, systemctl skips the bus and speaks the dbus protocol over a private socket.

strace will happily show you this:

$ strace -e connect systemctl --user >/dev/null
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/systemd/private"}, 33) = 0

$ strace -e connect systemctl >/dev/null
connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 30) = 0

So, it's expected that starting a user unit as a user doesn't trigger any activity visible through busctl monitor.
Comment by Jonas DOREL (jdorel) - Sunday, 14 July 2019, 12:56 GMT
Oh, thanks. So there is no way to passively monitor a user systemd instance ?

Anyway, should I close the bug or is the `at-spi-dbus-bus.service` initiating a dbus-daemon a bug in itself ?

Loading...