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.
Michael S. (Guest)
on 2009-05-07 01: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
Eric H. (Guest)
on 2009-05-07 01:21
(Received via mailing list)
On May 6, 2009, at 14:10, Michael S. 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.
Joel VanderWerf (Guest)
on 2009-05-07 01:22
(Received via mailing list)
Michael S. 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).
Joel VanderWerf (Guest)
on 2009-05-07 01:28
(Received via mailing list)
Joel VanderWerf wrote:
> Michael S. 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.
Robert K. (Guest)
on 2009-05-07 01:40
(Received via mailing list)
On 06.05.2009 23:10, Michael S. 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
Michael S. (Guest)
on 2009-05-07 03: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
Michael S. (Guest)
on 2009-05-07 03:55
Robert K. wrote:
> On 06.05.2009 23:10, Michael S. 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
Florian W. (Guest)
on 2009-05-07 09:35
(Received via mailing list)
Michael S. <removed_email_address@domain.invalid> 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
Simon K. (Guest)
on 2009-05-07 10:05
(Received via mailing list)
* Michael S. <removed_email_address@domain.invalid> (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
Robert K. (Guest)
on 2009-05-07 10:57
(Received via mailing list)
2009/5/7 Michael S. <removed_email_address@domain.invalid>:
>>
>> 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.