Battery notification script works on its own but does not work when triggered by a systemd-service

Question

On my Gentoo Linux with dunstify as a notification daemon and StumpWM as a window manager, I wrote the following bash-script that is meant to inform me about my battery status:

#!/bin/bash
#This script notifies you if your battery is under 80% and puts the laptop to sleep in 5min if it is under 50% and isn't plugged in within that time.

if ! [ -z "$(acpi -b | cut -c 25)" ] && [[ $(acpi -b | cut -c 25) -lt 8 ]] && ! [[ "$(  acpi -b | cut -c 28)" == "%" ]]
then if ! [ -z "$(acpi -b | cut -c 25)" ] && [[ $(acpi -b | cut -c 25) -lt 5 ]] && ! [[ "$(acpi -b | cut -c 28)" == "%" ]]
     then dunstify "Battery <50" "Battery under 50%, will sleep in 5min."
          sleep 5m
          if ! [ -z "$(acpi -b | cut -c 25)" ] && [[ $(acpi -b | cut -c 25) -lt 5 ]] && ! [[ "$(acpi -b | cut -c 28)" == "%" ]]
          then sudo systemctl suspend
          fi
     else dunstify "Battery <80" "Battery under 80%."
     fi
fi

This works when I trigger it manually. However, it's supposed to be periodically triggered by systemd every 10min or so and notify me if my battery is low. So I wrote the following systemd-service:

[Unit]
Description=Checks your battery.
RefuseManualStart=no
RefuseManualStop=yes
 
[Service]
Type=oneshot
ExecStart=/bin/battery

If the battery is above 80%, the service finishes without a problem, as it should. However, if it is below 80% it exits with an error. Looking at the log, I find the following:

░░ A start job for unit battery.service has begun execution.
░░ 
░░ The job identifier is 79311.
Jul 10 16:02:54 gentoolaptop battery[537360]: Connecting to D-Bus failed: Unable to autolaunc>Jul 10 16:02:54 gentoolaptop systemd[1]: battery.service: Main process exited, code=exited, s>░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://gentoo.org/support/
░░ 
░░ An ExecStart= process belonging to unit battery.service has exited.

I've been trying to run this as a user service, where I get this message, and as a system service, where I get told that XDISPLAY and XAUTHORITY isn't set. Why can't it send messages when triggered as a service?

Answer 1

The D-Bus session bus works similarly to the X server – there can be more than one per system, so clients must know the socket address to connect to, i.e. they need DBUS_SESSION_BUS_ADDRESS= which is the rough equivalent of DISPLAY=.

(This is distinct from the system bus which has a global socket address but only lets you talk to system services.)

So you must have the …_BUS_ADDRESS show up in systemctl --user show-environment alongside DISPLAY and XAUTHORITY; it might be easiest to do this by making sure your ~/.xinitrc (or other X startup script) calls systemctl --user import-environment [...] after starting the session bus.

---

There are two ways of starting a session bus:

• Traditional "session bus": At a randomly generated address under /tmp.

• Systemd-style "user bus": At a fixed location $XDG_RUNTIME_DIR/bus (/run/user/UID/bus).

It would be best to switch your system to the second method – I'm not entirely sure how that's done in Gentoo, but I think it requires building dbus with the systemd useflag, so that it would install dbus.service and dbus.socket user units, and removing any use of dbus-launch or dbus-run-session from your ~/.xinitrc or other X startup scripts.

Then your systemd --user instance will automatically start the bus at the "well known" location under /run/user (to be shared between your X session, all your tty sessions, and your services); some D-Bus clients will be able to find it there by default, but pam_systemd will also set DBUS_SESSION_BUS_ADDRESS to that location, and systemd --user itself will automatically know it.

Answer 2

It seems the problem for why my user systemd-service could communicate through dbus was that I was using startx to start my window manager but did not have the line

source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh 

in my .xinitrc, which I apparently should have put in at a position before the window manager in executed. With this line set now, the service works as it should.