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?
Access to user's session D-bus from their cron commands
cron;d bus
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 defaultsto using abstract sockets that exist only in memory and don't have acorresponding 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/shSESSION_MANAGER=lxsessionOUTFILE=/tmp/${USER}-cron-dbus.txtexport $(cat /proc/$(pgrep $SESSION_MANAGER -u $USER)/environ|egrep -z '^DBUS_SESSION_BUS_ADDRESS=')date >> $OUTFILEdbus-send --session --dest=org.example.Echo --print-reply /test/message org.example.Echo.Test >> $OUTFILEecho >> $OUTFILEThe 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.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 --sessionit 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 2015method return time=1450470422.206406 sender=:1.43 -> destination=:1.51 serial=10 reply_serial=2Otherwise, 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.