3 Use easier method of checking dbus' pulse, as suggested by Cheetah
source | link

However, we can use a variation on the idea presented in an ubuntuforum post, Attach to existing DBUS session over SSHAttach 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.

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

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

date >> $OUTFILE
dbus-send --session --dest=org.examplefreedesktop.EchoDBus --print-reply\
 /test  /message org.examplefreedesktop.EchoDBus.TestGetId >>2>> $OUTFILE
if test "$?" -eq 0; then
    echo "Success contacting session bus!" >> $OUTFILE
fi

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, ifIf 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 ->Success destination=:1.51contacting serial=10session reply_serial=2bus!

Otherwise, you'll just getsee the date line with no additionalerror message output. by dbus-send.

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.

#!/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.example.Echo --print-reply /test/message org.example.Echo.Test >> $OUTFILE
echo >> $OUTFILE

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.

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.

#!/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

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.

2 Fixed paragraph that follows script, to discuss SESSION_MANAGER variable more clearly.
source | link

If yourThe SESSION_MANAGER=lxsession above is appropriate for a main desktop session isn't running in the Gnome environmentunder LXDE, you canunder Gnome you'd set SESSION_MANAGER=lxsessionSESSION_MANAGER=gnome-session or, and under KDE you'd use SESSION_MANAGER=kded4 as appropriate.

If your session isn't running in the Gnome environment, you can set SESSION_MANAGER=lxsession or SESSION_MANAGER=kded4 as appropriate.

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.

1
source | link

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.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=lxsession or 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.