system call not working under cron

Discussion in 'Ruby' started by Michael Satterwhite, May 6, 2009.

  1. 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
    --
    Posted via http://www.ruby-forum.com/.
    Michael Satterwhite, May 6, 2009
    #1
    1. Advertising

  2. Michael Satterwhite

    Eric Hodel Guest

    On May 6, 2009, at 14:10, Michael Satterwhite wrote:

    > 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.
    Eric Hodel, May 6, 2009
    #2
    1. Advertising

  3. 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).

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
    Joel VanderWerf, May 6, 2009
    #3
  4. 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.

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
    Joel VanderWerf, May 6, 2009
    #4
  5. On 06.05.2009 23:10, Michael Satterwhite wrote:
    > 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
    Robert Klemme, May 6, 2009
    #5

  6. > 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
    --
    Posted via http://www.ruby-forum.com/.
    Michael Satterwhite, May 7, 2009
    #6
  7. 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
    --
    Posted via http://www.ruby-forum.com/.
    Michael Satterwhite, May 7, 2009
    #7
  8. Michael Satterwhite <> 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
    Florian Weingarten, May 7, 2009
    #8
  9. * Michael Satterwhite <> (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
    Simon Krahnke, May 7, 2009
    #9
  10. 2009/5/7 Michael Satterwhite <>:
    > 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. =A0Your cron job
    >> simply does not have access rights to the X session. =A0I do not know th=

    e
    >> details but the man page of "xhost" may be a good starting point. =A0Err=

    or
    >> 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


    --=20
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, May 7, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Schulz
    Replies:
    4
    Views:
    5,569
    Lee Fesperman
    Dec 27, 2004
  2. Stephen Cattaneo
    Replies:
    4
    Views:
    502
    Asun Friere
    Aug 19, 2008
  3. Cameron Simpson
    Replies:
    0
    Views:
    684
    Cameron Simpson
    Aug 18, 2008
  4. Sam
    Replies:
    4
    Views:
    586
    Lawrence D'Oliveiro
    Sep 24, 2008
  5. Nathan Pryor
    Replies:
    5
    Views:
    84
    Nathan Pryor
    Sep 12, 2003
Loading...

Share This Page