Forum: Ruby system call not working under cron

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
9e6d05909dc733af570faadce1392e67?d=identicon&s=25 Michael Satterwhite (msatterwhite)
on 2009-05-06 23:10
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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2009-05-06 23:21
(Received via mailing list)
On May 6, 2009, at 14:10, Michael Satterwhite wrote:

> 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.
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-05-06 23:22
(Received via mailing list)
Michael Satterwhite wrote:
> 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).
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-05-06 23:28
(Received via mailing list)
Joel VanderWerf wrote:
> Michael Satterwhite wrote:
>> ret = system("gconftool -t str --set
>> /desktop/gnome/background/picture_filename '#{new_picture}'")
> ...
>
> OT, but should that be
>
>   -t #{str}
>
> ?

Never mind, I see now that "str" is a gconftool switch param.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-05-06 23:40
(Received via mailing list)
On 06.05.2009 23:10, Michael Satterwhite wrote:
>
> 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
9e6d05909dc733af570faadce1392e67?d=identicon&s=25 Michael Satterwhite (msatterwhite)
on 2009-05-07 01:53
> 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
9e6d05909dc733af570faadce1392e67?d=identicon&s=25 Michael Satterwhite (msatterwhite)
on 2009-05-07 01:55
Robert Klemme wrote:
> On 06.05.2009 23:10, Michael Satterwhite wrote:
>>
>> 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.

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
1e1c99cc311b6e779f2fd40a1ce04021?d=identicon&s=25 Florian Weingarten (Guest)
on 2009-05-07 07:35
(Received via mailing list)
Michael Satterwhite <michael@weblore.com> wrote:
>> Use full paths in cron and scripts run from cron, as cron has a
>> limited environment.  /path/to/gconftool will fix this.

> 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
1d53b088a989e069b94597c282eebbbc?d=identicon&s=25 Simon Krahnke (Guest)
on 2009-05-07 08:05
(Received via mailing list)
* Michael Satterwhite <michael@weblore.com> (23:10) schrieb:

> 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-05-07 08:57
(Received via mailing list)
2009/5/7 Michael Satterwhite <michael@weblore.com>:
>>
>> 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.

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
This topic is locked and can not be replied to.