Access to user's session D-bus from their cron commands

Question

What is needed to give cron commands access to the session bus (if it is running)?

It used to work for me, on Debian Stretch (testing) since switching systemd until relatively recently (might have been month or two ago). The strange thing is that while I strongly suspect this is controlled by the PAM configuration, the only change that happened to /etc/pam.d recently enough was adding some calls to pam_selinux to pam.d/systemd-user.

So what should I look for?

Answer 1

This is likely due to the fact that the DBUS_SESSION_BUS_ADDRESS environment variable isn't propagated to the cron environment.

At least under Gnome, the bus isn't made "discoverable" (as documented in the "AUTOMATIC LAUNCHING" section of the dbus-launch(1) man page) via files in $HOME/.dbus/session-bus. This leaves anything run in your crontab without a way to discover $DBUS_SESSION_BUS_ADDRESS and contact the session D-Bus.

I'll take your word for it that it worked in the past, possibly due to use of $HOME/.dbus or the existence of actual /tmp/dbus-$TMPNAM files referenced in $DBUS_SESSION_BUS_ADDRESS (which is normally set to something resembling unix:abstract=/tmp/dbus-GkJdpPD4sk,guid=0001e69e075e5e2). As the dbus-cleanup-sockets(1) man page explains:

On Linux, this program is essentially useless, because D-Bus defaults to using "abstract sockets" that exist only in memory and don't have a corresponding file in /tmp.

However, we can use a variation on the idea presented in an ubuntuforum post, Attach to existing DBUS session over SSH, to discover the session D-Bus of an existing user session on the local machine from within the cron environment and set $DBUS_SESSION_BUS_ADDRESS accordingly.

While the technique used there discovers the environment from commonly-running processes like nautilus, pulseaudio, and trackerd, and requires that one or more of them be running in the active session, I recommend a more basic approach.

All of the common desktop environment session managers (gnome-session, lxsession, and kded4) have $DBUS_SESSION_BUS_ADDRESS set in their environment, even though they're started before dbus-daemon and have lower PIDs. So, it makes the most sense to just use whatever session manager corresponds to your desktop environment.

I wrote the following script, placed in $HOME/bin/test-crontab-dbus.sh, to test access to the existing session bus:

#!/bin/sh
SESSION_MANAGER=lxsession
OUTFILE=/tmp/${USER}-cron-dbus.txt

export $(cat /proc/$(pgrep "$SESSION_MANAGER" -u "$USER")/environ \
  |egrep -z '^DBUS_SESSION_BUS_ADDRESS=')

date >> $OUTFILE
dbus-send --session --dest=org.freedesktop.DBus \
   / org.freedesktop.DBus.GetId 2>> $OUTFILE
if test "$?" -eq 0; then
    echo "Success contacting session bus!" >> $OUTFILE
fi

The SESSION_MANAGER=lxsession above is appropriate for a main desktop session running under LXDE, under Gnome you'd set SESSION_MANAGER=gnome-session, and under KDE you'd use SESSION_MANAGER=kded4.

If the job in the crontab has access to the session bus, you'll see something like the following in the output:

Fri Dec 18 15:27:02 EST 2015
Success contacting session bus!

Otherwise, you'll see the error message output by dbus-send.

Obviously, you can substitute any other method of testing connectivity to the session bus, including whatever operation you actually need to perform via a cron job.