system call not working under cron

[Michael Satterwhite]

I have a short ruby script to periodically change the screen background
under gnome (Ubuntu Linux). Trace statements in the script show that the
script itself is running. The problem is that the system() call is not
working. Note that I'm running it as myself, not as root. The same
script works perfectly when run in a console.

Here's the command that isn't working.

ret = system("gconftool -t str --set
/desktop/gnome/background/picture_filename '#{new_picture}'")

Please accept that the "new_picture" variable has a good value pointing
to a new background. There are traces in the program that write values
to a trace file that I can examine after the fact. The fact that the
trace file is updated also shows the script is running.

Does anyone know why this command would work from a console, but not
from a cron job?

Thanks in advance
---Michael

 

[Eric Hodel]

I have a short ruby script to periodically change the screen
background
under gnome (Ubuntu Linux). Trace statements in the script show that
the
script itself is running. The problem is that the system() call is not
working. Note that I'm running it as myself, not as root. The same
script works perfectly when run in a console.

Here's the command that isn't working.

ret = system("gconftool -t str --set
/desktop/gnome/background/picture_filename '#{new_picture}'")

Please accept that the "new_picture" variable has a good value
pointing
to a new background. There are traces in the program that write values
to a trace file that I can examine after the fact. The fact that the
trace file is updated also shows the script is running.

Does anyone know why this command would work from a console, but not
from a cron job?

Use full paths in cron and scripts run from cron, as cron has a
limited environment. /path/to/gconftool will fix this.

 

[Joel VanderWerf]

ret = system("gconftool -t str --set
/desktop/gnome/background/picture_filename '#{new_picture}'")

...

OT, but should that be

-t #{str}

?

Does anyone know why this command would work from a console, but not
from a cron job?

Have you set up the PATH env var so that the command is found? Cron jobs
run in a very basic environment, so it may not be finding the program
(though apparently it did find ruby).

 

[Joel VanderWerf]

...

OT, but should that be

-t #{str}

?

Never mind, I see now that "str" is a gconftool switch param.

 

[Robert Klemme]

I have a short ruby script to periodically change the screen background
under gnome (Ubuntu Linux). Trace statements in the script show that the
script itself is running. The problem is that the system() call is not
working. Note that I'm running it as myself, not as root. The same
script works perfectly when run in a console.

Here's the command that isn't working.

ret = system("gconftool -t str --set
/desktop/gnome/background/picture_filename '#{new_picture}'")

Please accept that the "new_picture" variable has a good value pointing
to a new background. There are traces in the program that write values
to a trace file that I can examine after the fact. The fact that the
trace file is updated also shows the script is running.

Does anyone know why this command would work from a console, but not
from a cron job?

This is likely due to X11's handling of permissions. Your cron job
simply does not have access rights to the X session. I do not know the
details but the man page of "xhost" may be a good starting point. Error
message that you get might also be a good indication.

Kind regards

robert

 

[Michael Satterwhite]

Use full paths in cron and scripts run from cron, as cron has a
limited environment. /path/to/gconftool will fix this.

I really had high hopes for this one ... it seemed like a "how dumb can
I be moment". Unfortunately, putting the path to gconftool into the
script made no difference. Still works from console and does nothing
from cron.

---Michael

 

[Michael Satterwhite]

This is likely due to X11's handling of permissions. Your cron job
simply does not have access rights to the X session. I do not know the
details but the man page of "xhost" may be a good starting point. Error
message that you get might also be a good indication.

I didn't even know about xhost before this. According to the
documentation, the command "xhost" without arguments will list those who
have authorization for the xserver. My user id was authorized already -
still won't run from cron.

I did learn something from this one, though. Thanks
---Michael

 

[Florian Weingarten]

script made no difference. Still works from console and does nothing

Did you give your images name as full path also? Do you run as cronjob (as in
/etc/cron.hourly/ or something, or as crontab?). Try using crontab, then your
script will be started as your user, as far as I know, maybe that helps.

Do you get any error messages (logfile)?

Flo

 

[Simon Krahnke]

ret = system("gconftool -t str --set
/desktop/gnome/background/picture_filename '#{new_picture}'")

Does gconftool need the DISPLAY environment variable? That probably
wouldn't be there from cron but in any terminal started from X.

If that's the case, system("DISPLAY=:1 gconftool ...") should work,
replace ":1" by whatever $DISPLAY is in your terminal.

mfg, simon .... l

 

[Robert Klemme]

I didn't even know about xhost before this. According to the
documentation, the command "xhost" without arguments will list those who
have authorization for the xserver. My user id was authorized already -
still won't run from cron.

If you executed the xhost command from a terminal started from your X
session this comes as no surprise. You should see different results
when executing from the cron job.

The point is that since cron is not a child of the X server process
your job does not automatically inherit certain permissions.

The point is, a cron job is usually not the proper thing to update an
X session because cron is something permanent while X sessions are
transitional. Rather you want to start your screen updater as part of
the X session initialization (~/.xinitrc IIRC). Then your process
will inherit all the necessary permissions and DISPLAY will also be
set properly.

Kind regards

robert


--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/