Results 1 to 8 of 8

Thread: AT and CRON/CRONTAB, uncertainties

  1. #1
    Join Date
    Mar 2013
    Location
    Dallas, Texas (not a Native )
    Posts
    17

    Question AT and CRON/CRONTAB, uncertainties

    I can make them both work, but in each case, it takes several, frustrating workarounds.

    AT is a strange duck. I can "at -f someScript now + 2 minutes", as the documentation allows,
    and a proper display is returned. BUT, 5 minutes later, if I do an atq, the jobs in the queue are listed,
    and invariably the job submitted is still there, and will remain there. To force it out, I submit
    "at -f dummyAt now" which causes the previously submitted job to run.

    I do this from the command line in Konsole, as a "regular user".

    CRONTAB will give you heartburn. While AT gives you access to all exported variables, Crontab does not.
    For example, $SHLVL and the other system, exported variables are accessible in a script that is run by Cron.
    But, other variables that I set and export in .bashrc, are not accessible; e.g., $binDir which is my personal bin.
    No way! You want it, set it in the script, and a complete path, not a relative one.

    Any suggestions will be greatly appreciated and duly researched.

    Regards,
    Frank G.

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,142

    Default Re: AT and CRON/CRONTAB, uncertainties

    It seems that you failed to read the man page of crontab
    Code:
    man 5 crontab
    It tells you a lot about environment variables and also that it used sh and not bash.
    Henk van Velden

  3. #3
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: AT and CRON/CRONTAB, uncertainties

    On 2015-05-26 07:36, frankeG wrote:
    >
    > I can make them both work, but in each case, it takes several,
    > frustrating workarounds.
    >
    > AT is a strange duck. I can "*at -f someScript now + 2 minutes*", as
    > the documentation allows,
    > and a proper display is returned. BUT, 5 minutes later, if I do an
    > *atq*, the jobs in the queue are listed,
    > and invariably the job submitted is still there, and will remain there.


    Are you sure the atd daemon is running? I think it is not enabled by
    default nowdays.

    Code:
    systemctl status atd.service
    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  4. #4

    Default Re: AT and CRON/CRONTAB, uncertainties

    Hi,

    Yes, like what Henk said you need to define your own PATH and either in the crontab file itself (if you want to just add a single line of code in the crontab file) or put it in the script you want to call from crontab.

    Code:
    echo "$PATH" 2>&1 >> /tmp/path
    inside the crontab file and see what/which PATH is in available.
    of course you need to define the * * * * * * entry in crontab.
    "Unfortunately time is always against us" -- [Morpheus]

    .:https://github.com/Jetchisel:.

  5. #5
    Join Date
    Mar 2013
    Location
    Dallas, Texas (not a Native )
    Posts
    17

    Default Re: AT and CRON/CRONTAB, uncertainties

    Many thanks for the responses which I have read, and will do some further experimenting, after which I shall return with findings.
    And, I shall read more manpages.

    Regards,
    Frank G.

  6. #6
    Join Date
    Mar 2013
    Location
    Dallas, Texas (not a Native )
    Posts
    17

    Red face Re: AT and CRON/CRONTAB, uncertainties

    Robin_Listas ( of the fuzzy bird Avatar) points out:
    Are you sure the atd daemon is running? I think it is not enabled by default nowdays.
    And, he is quite correct; I inserted a start statement into my .bashrc so it is started automatically every time.
    Previously I was issuing a simple
    Code:
    atd
    at the command line. Now, the need for a second at no longer exists, and the commands are run at the correct time; much nicer to work with.

    Now, the issue of crontab: Suggestions of Jetchisel and Carlos were most helpful:
    It tells you a lot about environment variables and also that it used sh and not bash.
    Yes, like what Henk said you need to define your own PATH and either in the crontab file itself (if you want to just add a single line of code in the crontab file) or put it in the script you want to call from crontab.
    Code:
    echo "$PATH" 2>&1 >> /tmp/path
    inside the crontab file and see what/which PATH is in available.
    of course you need to define the * * * * * * entry in crontab.
    Both suggestions led to a lot of testing, learning, and relief. I ran the simplest of tests, and as Henk points out, what you get, from SH, is a very basic set of environmental variables. Then following the next suggestion, I am still playing with this, but I think the major problem is solved, lack of learning, and I can move forward.

    I have some other problems to work on, but when I finish with them, I shall continue with crontab and post some general facts of use
    that may be helpful to others.


    Many thanks to all who responded and those who took the time to read and reason with my problem;

    Regards
    Frank G. (summer smile in Dallas)

  7. #7
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: AT and CRON/CRONTAB, uncertainties

    On 2015-06-10 02:56, frankeG wrote:
    >
    >> Robin_Listas ( of the fuzzy bird Avatar) points out:
    >> Are you sure the atd daemon is running? I think it is not enabled by
    >> default nowdays.

    > And, he is quite correct; I inserted a start statement into my .bashrc
    > so it is started automatically every time.


    Huh, no, that's not the way.

    Do, in a terminal:

    Code:
    su -
    systemctl status atd.service
    systemctl start atd.service
    systemctl enable atd.service
    systemctl status atd.service
    It the last command above says loaded and enabled, it should start
    automatically on next boot.

    --
    Cheers / Saludos,

    Carlos E. R.

    (from 13.1 x86_64 "Bottle" (Minas Tirith))

  8. #8
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,142

    Default Re: AT and CRON/CRONTAB, uncertainties

    Quote Originally Posted by frankeG View Post
    inserted a start statement into my .bashrc so it is started automatically every time.
    Previously I was issuing a simple
    Code:
    atd
    at the command line. Now, the need for a second at no longer exists, and the commands are run at the correct time; much nicer to work with.
    ??????????

    I am not sure what this does do, but in any case I am realy amazed that it does run owned by an end-user and still functions.

    And one can only guess (I am not willing to test this) what happens on log-out, and/or second log-in.

    It is a system daemon. should be started by root and Carlos gives you the correct way to do this.
    Henk van Velden

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •