Created attachment 6468 Add a systemd user unit corresponding to the D-Bus session service This lets systemd put the service in its own cgroup, instead of treating it as part of dbus.service. --- Another one similar to Bug #12225.
Hi! I'm probably not the most experienced person regarding systemd units, but I can't get this to work. The errors I'm running into are Unable to init server: Could not connect: Connection refused (xfce4-notifyd:8870): Gtk-WARNING **: cannot open display: Is there anything you'd expect me to do with systemd after installing this unit in order for it to work (other than "systemctl daemon-reload"?
For this to be useful, you need to be running a version/configuration of D-Bus where your "dbus-daemon --session" is a systemd user service run by "systemd --user", and the X11 DISPLAY (if you are using X11) needs to be propagated to both systemd --user and dbus-daemon --session. Making dbus-daemon --session be a systemd user service ------------------------------------------------------ In Debian and its derivatives like Ubuntu, you get that by installing the dbus-user-session package (it's "opt-in"). Read its Description before installing it. In recent Fedora and Arch Linux, you get that by just upgrading; their D-Bus packages don't support any other mode any more. If you are building your own copy of D-Bus from source, configure dbus >= 1.10 with --enable-user-session. I don't know what other distributions have done. Getting the X11 DISPLAY propagated ---------------------------------- Unfortunately this is distribution-specific. In Debian and its derivatives, this snippet in /etc/X11/Xsession.d/ is the minimal implementation: https://anonscm.debian.org/cgit/pkg-utopia/dbus.git/tree/debian/20dbus_xdg-runtime In Red Hat derivatives, I think the equivalent directory is /etc/X11/xinit/xinitrc.d/ or something.
(In reply to Simon Steinbeiss from comment #1) > Is there anything you'd expect me to do with systemd after installing this > unit in order for it to work (other than "systemctl daemon-reload"? You're not really meant to start it manually, or even make other units depend on it (although you can): it's mostly there so that, in the setup I described in Comment #2, it can be used for D-Bus activation. If the dbus-daemon was started as a systemd user service (with the --systemd-activation command-line option), and it sees a D-Bus .service file with the SystemdService key, it will delegate the actual launching to systemd instead of doing a fork-and-exec itself. Here's part of systemd-cgls on a system using this unit and the one from Bug #12225: └─user.slice └─user-1000.slice ├─session-1.scope │ ├─764 /usr/sbin/nodm │ ├─774 /bin/sh -l -c /etc/X11/Xsession │ ├─776 /bin/sh /etc/xdg/xfce4/xinitrc │ ├─803 /usr/bin/ssh-agent x-session-manager │ ├─813 xfce4-session │ ├─827 gnome-keyring-daemon --start ... │ └─964 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 ... ... ├─user@1000.service │ ├─dbus.service │ │ ├─785 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopid │ │ ├─936 /usr/lib/at-spi2-core/at-spi-bus-launcher │ │ ├─943 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf │ │ └─945 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session ... │ └─xfce4-notifyd.service │ └─20132 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd xfce4-notifyd would traditionally have ended up alongside at-spi2-registryd and at-spi-bus-launcher (which I thought I'd fixed in the same way as this, I'll need to take another look at those), which means systemd thinks it's part of dbus-daemon - all the resource-control, etc., would be the same. With this service file, it ends up in its own parallel cgroup instead.
Thanks, that makes sense! FWIW Toz took your patch for a spin and it's working fine so I pushed it to master: http://git.xfce.org/apps/xfce4-notifyd/commit/?id=cf683fa5636e276d2f592bcd9bacb4efb04e79f0