using crontab

[Stewbond]

I have a script to randomly change my wallpaper: /home/stew/bin/wallppr.sh. When I call the script, it works fine.

I'd like to call it every x time. I've tried the "watch" command, but I seem to need a dedicated terminal open at all times for that. After discovering crontab, it looks good (it can do hourly) so I've tried implementing it but it doesn't seem to have an effect.

To implement it, I simply ran

Code: Select all

crontab -e

and added the following line:

Code: Select all

@hourly wallppr.sh

I don't see my desktop wallpaper change (which I see if I run the script manually). But when I look in /var/log/syslog, I see the following every hour:

Code: Select all

Feb 11 19:00:01 Romulus CRON[2564]: (stew) CMD (wallppr.sh)
Feb 11 19:00:01 Romulus CRON[2563]: (stew) MAIL (mailed 1 byte of output; but got status 0x00ff, #012)

What could the problem be?

I can confirm that the Path enviornment variable contains my ~/bin directory. This is the script I am trying to call:

Code: Select all

#!/bin/bash
pic=(~/Pictures/Wallpapers/*)
gsettings set org.gnome.desktop.background picture-uri \
        "file://${pic[RANDOM % ${#pic[@]}]}"


[xenopeek]

First rule of crontab is, redirect your stdout and stderr to a logfile! Else you will never figure out what is going wrong

Start your script with something like (where you replace username with your username):

Code: Select all

#!/bin/bash

# redirect stdout and stderr to logfile
exec >>/home/username/logfile.log 2>&1

# your code goes below here

[Stewbond]

I was wondering how to redirect those in linux. Thanks.

Now to wait another 21 minutes for it to try again...

[bjornmu]

When the cron job runs, it will likely have a minimalistic PATH so you probably have to specify the full path to your script in the crontab entry. I.e. /home/stew/bin/wallppr.sh and not just wallppr.sh. That may be the second rule of crontab: don't assume any PATH beyond /bin and /usr/bin.

[xenopeek]

Are we making these rules up as we go along But you are right bjornmu and that is probably also the problem here.

[Stewbond]

Thanks for the info. I threw some echo's in there and discovered that the script wasn't called. Therefore I've changed my crontab command from:
@hourly wallppr.sh
to
@hourly /home/stew/bin/wallppr.sh

After leaving my desktop overnight, I now log the following error from stderr:

Code: Select all

Tue Feb 12 07:00:01 CET 2013: Changing wallpaper

** (process:8781): WARNING **: failed to commit changes to dconf: Error spawning command line `dbus-launch --autolaunch=632ccd39a35069024be3e9e7510e38de --binary-syntax --close-stderr': Child process exited with code 1


My script now looks like this:

Code: Select all

#!/bin/bash

# redirect stdout and stderr to logfile
exec >> /home/stew/log/wallppr.log 2>&1

echo "$(date): Changing wallpaper"

# randomly choose wallpaper
pic=(/home/stew/Pictures/Wallpapers/*)
gsettings set org.gnome.desktop.background picture-uri \
        "file://${pic[RANDOM % ${#pic[@]}]}"

My question now is: is this happening because I crontab doesn't have rights to my /home/ directory? Is there a way around this? wallppr.sh has rights: chmod 755 wallppr.sh

[Stewbond]

Ah, so I've added the script the ~/.profile and I get the same error. That means it's a problem with the gsettings command when run by the system (or at least not in the terminal).

Somehow, when I manually run this in the terminal, I can write to the dconf without issue.

When I run it via a system command (crontab or login script), I lose permissions or some other bug exists. Ideas?

[catweazel]

When I run it via a system command (crontab or login script), I lose permissions or some other bug exists. Ideas?

http://www.ibm.com/developerworks/linux/library/l-job-scheduling/index.html

[Stewbond]

Thanks for the link. I've now learned how to schedule my wallpaper script to run every 10 minutes, but it also fails now every 10 minutes.

The only information that I found here was that my system did not have /etc/cron.allow or /etc/cron.deny. I've therefore created /etc/cron.deny as an empty file to allow "all" users access to crontab. Unfortunately, this has had no effect when re-creating my crontabs.

Does anyone have any other ideas? Could it be a bug with gsettings?

[Stewbond]

I've figured out the exact problem!
If I run the following in the terminal I have no problem:

Code: Select all

gsettings set org.gnome.desktop.background picture-uri file:///home/stew/pic.jpg

As soon as I use the following, It stops working:

Code: Select all

sudo gsettings set org.gnome.desktop.background picture-uri file:///home/stew/pic.jpg

Is there a way to run crontab as a specific user and not as root?

[bjornmu]

Yes you can certainly run cron jobs as yourself. If you run crontab as yourself, that's what will happen. There is no need for sudo.

[Stewbond]

Hmm in this case I'm really at a loss.

When I run "sudo crontab -e" I have an empty crontab file. When I run "crontab -e" as myself, I have a crontab file with my script in it.

[bjornmu]

OK so you did edit your crontab.

Ah, I think you have to set $HOME in your script; this will not be set automatically when running cron jobs. gsettings would need $HOME so find your config files.

Code: Select all

export HOME=/home/stew

[Stewbond]

With this change I can now call the scipt as sudo without any errors from stderr.

Unfortunately the script has no effect (other than my echo) when called as sudo. In crontab, I still get the stderr message.

I'm going to search for alternatives to gsettings