I'm using Debian Stretch. I have a crontab entry which I have used in numerable linux distributions with no problems, but for some reason it doesn't work in Debian Stretch with the mate desktop. I also use the window manager pekwm, and the entry works fine. But not in mate. What makes it more problematic, the same entry works fine with mate in other distros, like Devuan and Slackware. Here's the entry:

*/7 * * * * DISPLAY=:0 /home/ewl/bin/testwm

testwm is a script which tests what window manager or desktop environment is running and uses the appropriate command for that wm to change the wallpaper. Here's the script:

#!/bin/bash
x=`ps -e | grep mate-session`
y=`ps -e | grep pekwm`
z=`ps -e | grep dwm`
if [[ -n $x ]]
then /home/ewl/bin/materia
elif [[ -n $y ]]
then /home/ewl/bin/randfeh
elif [[ -n $z ]]
then xsetroot -solid black
fi


materia is a script that changes the desktop in mate and randfeh changes the wallpaper in wm's that use feh to display wallpaper. When I run testwm and materia by themselves in a terminal in mate, the scripts work fine. But it won't run in crontab, under mate. But it does run in crontab in pekwm.

What does /var/log/cron have to say about it?

I have no /var/log/cron

Here's all references to CRON in /var/log/syslog:

Jun 30 15:42:01 porter CRON[8710]: (ewl) CMD (DISPLAY=:0^I/home/ewl/bin/testwm)
Jun 30 15:49:01 porter CRON[8859]: (ewl) CMD (DISPLAY=:0^I/home/ewl/bin/testwm)
Jun 30 18:17:52 porter cron[377]: (CRON) INFO (pidfile fd = 3)
Jun 30 18:17:52 porter cron[377]: (CRON) INFO (Running @reboot jobs)
Jun 30 18:21:01 porter CRON[1312]: (ewl) CMD (DISPLAY=:0^I/home/ewl/bin/testwm)

And here's all references to cron, lower case:

Jun 30 15:35:51 porter anacron[411]: Job `cron.daily' terminated
Jun 30 15:35:51 porter anacron[411]: Normal exit (1 job run)
Jun 30 15:35:51 porter systemd[1]: anacron.timer: Adding 3min 40.093320s random time.
Jun 30 15:53:25 porter systemd[1]: Stopped Trigger anacron every hour.
Jun 30 18:17:52 porter cron[377]: (CRON) INFO (pidfile fd = 3)
Jun 30 18:17:52 porter cron[377]: (CRON) INFO (Running @reboot jobs)
Jun 30 18:17:52 porter systemd[1]: anacron.timer: Adding 1min 46.073334s random time.
Jun 30 18:17:52 porter systemd[1]: Started Trigger anacron every hour.
Jun 30 18:17:52 porter systemd[1]: Started Run anacron jobs.
Jun 30 18:17:52 porter systemd[1]: anacron.timer: Adding 40.482244s random time.
Jun 30 18:17:52 porter systemd[1]: anacron.timer: Adding 3min 1.838896s random time.
Jun 30 18:17:52 porter anacron[398]: Anacron 2.3 started on 2019-06-30
Jun 30 18:17:52 porter anacron[398]: Normal exit (0 jobs run)
Jun 30 18:17:52 porter systemd[1]: anacron.timer: Adding 3min 6.490945s random time.
Jun 30 18:18:21 porter systemd[1]: anacron.timer: Adding 27.553187s random time.

Drat. I have one on Slackware, but I don't have one on the Ubuntu MATE box over there---->.

Nice job hunting down those other references. Nothing in them looks like what I saw in /var/log/cron for the cronjob I recently misconfigured.

I must admit that I'm puzzled as to how a GUI environment could affect a cron job.

Would it be possibel to see the relevant line for that cronjob?

I've only got one cronjob with my userid. This is crontab -l

#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
*/7 * * * * DISPLAY=:0 /home/ewl/bin/testwm

Failing to quote the variable with -n is a common mistake. This test always returns true,

But the failure of the script isn't the problem. It works when I call it by itself. It just doesn't work when I call it in a cronjob... in mate... in debian. It works in pekwm in crontab, and it works in crontab and mate when I'm running the same scripts and cronjob in slackware and devuan. So I don't think that's the problem. I did change it and it didn't fix it.

I've kind of given up on this and have installed "variety" to handle changing wallpaper. I thought a cron job would be simpler, but apparently there's a problem.

This is a complete shot in the dark, but you might try turning

into a script and calling that script from cron.

Also, if you have a script that changes the background in MATE, I'd love to see it. I have a little script that uses fbsetbg in Fluxbox, and I set up slideshow in KDE, but MATE doesn't offer a "slideshow" option.

For the script I had to put DISPLAY=:0 and /home/ewl/bin/testwm on different lines. But after creating that script and calling it in cron, it didn't solve the problem.

The script to change mate's wallpaper I call "materia" for no particular reason. It has "mate" in it. But here it is. My wallpapers are in /home/ewl/Pictures/Wallpapers/ :

#!/bin/sh
# Script to randomly set Background from files in a directory

# Directory Containing Pictures
DIR="/home/ewl/Pictures/Wallpapers"

# Command to Select a random jpg file from directory
# Delete the *.jpg to select any file but it may return a folder
PIC=$(ls $DIR/* | shuf -n1)

# Command to set Background Image
gsettings set org.mate.background picture-filename $PIC

Hi,

/var/log/syslog seems to indicate that the script is being called.
To find out why it is not doing what you expect I suggest you add some debugging to the script. Eg something like:
HTH,

Evo2.

1 members found this post helpful.

Whenever I've run into this kind of problem, i.e. a script runs OK for the user but fails when called as a cron job, it invariably turned out to be due to the cron environment and the user environment having PATH differences. It's usually fixed by rewriting the script to have full absolute paths to all called locations and executables.

Excellent idea. Crontab apparently called testwm which called materia, but I got no response on the desktop. If I call materia manually, it does change the wallpaper. But it didn't do that through crontab. Here's testwm.log:

Thu Jul 4 11:21:01 EDT 2019
DISPLAY is :0
x is 9667 ? 00:00:00 mate-session
y is
z is
Called /home/ewl/bin/materia
Done!