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
While the technique used there discovers the environment from commonly-running processes like
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 (
$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:
export $(cat /proc/$(pgrep "$SESSION_MANAGER" -u "$USER")/environ|egrep -z '^DBUS_SESSION_BUS_ADDRESS=')
date >> $OUTFILE
dbus-send --session --dest=org.example.Echo --print-reply /test/message org.example.Echo.Test >> $OUTFILE
echo >> $OUTFILE
If your session isn't running in the Gnome environment, you can set
SESSION_MANAGER=kded4 as appropriate.
This works in concert with
dbus-test-tool, which is included in the
dbus-1.10.6-1.fc23 package on Fedora 23 (but not present in earlier Fedora releases). Invoked like so:
dbus-test-tool echo --name=org.example.Echo --session
it will sit on the session bus and simply echo a valid reply to any message sent to it. So, if the job in the crontab has access to the session bus, and
dbus-test is running, you'll see something like the following in the output:
Fri Dec 18 15:27:02 EST 2015
method return time=1450470422.206406 sender=:1.43 -> destination=:1.51 serial=10 reply_serial=2
Otherwise, you'll just get the date line with no additional output.
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.