Provide systemd user service

[matthewbauer]

For packaging this, it would be useful to have a systemd user service that users can enable. I think? we can make this bus activated like in https://www.freedesktop.org/software/systemd/man/systemd.service.html#id-1.10.6.

[rfjakob]

I'm seeing interesting failures when started via systemd. Investigating.

May 21 16:25:44 brikett systemd[1287]: Started systembus-notify.service.
May 21 16:25:44 brikett systembus-notify[111696]: connecting to d-bus user bus: ok
May 21 16:25:44 brikett systembus-notify[111696]: connecting to d-bus system bus: ok
May 21 16:25:44 brikett systembus-notify[111696]: waiting for d-bus signals on system bus: type='signal',interface='net.nuetzlich.SystemNotifications',m>
May 21 16:27:24 brikett systembus-notify[111696]: received d-bus signal on system bus
May 21 16:27:24 brikett systembus-notify[111696]: ↳ summary: summary text only
May 21 16:27:24 brikett systembus-notify[111696]: ↳ body:    (null)
May 21 16:27:24 brikett systembus-notify[111696]: sd_bus_call: Connection timed out

[rfjakob]

The Connection timed out problem is not related to the user session. But I noticed another problem: creating a systemd user unit means that systembus-notify also runs when a user logs in via ssh etc, which does not make sense.

I think what we currently do (putting the .desktop file into the xdg autostart folder) is better.

[max-baz]

@rfjakob I started using systembus-notify today and somehow got the same failures you posted above several times, not using systemd, just plainly running the executable manually. Couldn't find any good repro steps, but I just saw you pushed some commits that address the issues, e.g. exiting the process on lost connection. Could you maybe tag a new release from master?

I'm also thinking to add a systemd service in my setup, for one simple reason: if systembus-notify crashes (e.g. due to the error above), I want the process to automatically restart. I will be looking into how to ensure that a systemd service only starts in a graphical session, don't know yet how to achieve this 🙂 If you want I can let you know if/when I get something that I'm satisfied with.

[ahmubashshir]

@rfjakob I started using systembus-notify today and somehow got the same failures you posted above several times, not using systemd, just plainly running the executable manually. Couldn't find any good repro steps, but I just saw you pushed some commits that address the issues, e.g. exiting the process on lost connection. Could you maybe tag a new release from master?

I'm also thinking to add a systemd service in my setup, for one simple reason: if systembus-notify crashes (e.g. due to the error above), I want the process to automatically restart. I will be looking into how to ensure that a systemd service only starts in a graphical session, don't know yet how to achieve this If you want I can let you know if/when I get something that I'm satisfied with.

is it possible to use ExecCond to check DISPLAY variable?

[Unit]
Description=systembus notifier

[Service]
ExecCondition=/bin/test -n $DISPLAY
ExecStart=/usr/bin/systembus-notify
Restart=always

[Install]
WantedBy=default.target

it works on my box...

[max-baz]

is it possible to use ExecCond to check DISPLAY variable?

Technically yes, in practice you want to use the standard graphical-session.target instead (which means some kind of graphical session is running). This will let systembus-notify start automatically when any WM starts and automatically shutdown when the WM stops.

Here's the service file I would recommend (latest link):

[Unit]
Description=Show desktop notifications for earlyoom
PartOf=graphical-session.target
After=graphical-session.target

[Service]
ExecStart=/usr/bin/systembus-notify -q

[Install]
WantedBy=graphical-session.target

I didn't add Restart=always because I am monitoring the failed services and would like to be notified when a service breaks. I've been running this service for a couple of weeks now, and it hasn't failed a single time (using the build from master).

WantedBy means it will start together with graphical session if you enable the service, After means it will wait for graphical session to finish loading before starting, PartOf means the service with stop when graphical-session stops.

[rfjakob]

Tagged v1.1 now. Reopening, graphical-session.target looks pretty good.

[max-baz]

Cool!

I just realized we can try to improve even further and in addition to WantedBy have DBUS activation, so that for those who want there will be an alternative option not to start service on startup, but start it only when there is a message on DBUS (and graphical session is running), and it will still auto-stop if graphical session ends.

I'll get back to you as soon as I make it work 🙂

[max-baz]

D-BUS activation doesn't seem to work for me, probably for the similar reason this project exists in the first place, a user-level systemd service can only be started by a session bus, not system one. So what I posted above is the best proposal I have.

[matejdro]

graphical-session.target did not work for me on Arch + i3, I had to switch back to default.target. It seems like graphical-session,target is unreliable in general: https://unix.stackexchange.com/a/598055/445842