Professional Web Applications Themes

Changing Date Results in Cron Jobs not Running - SCO

When our company turns the year, they want me to reset the date back to Sep 30 each day until we have finished all accounting for that year. Stupid I know. (Our year is Oct 1 - Sep 30) My problem is this causes all backup and maintenance tasks scheduled not to run. What does scosh cronsched -r and scosh cronsched -wr do? I can find no doentation for cronsched. If I run it after setting the date, will it reschedule the cron jobs? Any other ideas or suggestions? Peter McGill...

  1. #1

    Default Changing Date Results in Cron Jobs not Running

    When our company turns the year, they want me to reset the date back
    to Sep 30 each day until we have finished all accounting for that
    year. Stupid I know. (Our year is Oct 1 - Sep 30)

    My problem is this causes all backup and maintenance tasks scheduled
    not to run.

    What does scosh cronsched -r and scosh cronsched -wr do?
    I can find no doentation for cronsched.

    If I run it after setting the date, will it reschedule the cron jobs?

    Any other ideas or suggestions?

    Peter McGill
    Peter Guest

  2. #2

    Default Re: Changing Date Results in Cron Jobs not Running

    Peter McGill typed (on Tue, Oct 07, 2003 at 05:28:07PM +0000):
    | When our company turns the year, they want me to reset the date back
    | to Sep 30 each day until we have finished all accounting for that
    | year. Stupid I know. (Our year is Oct 1 - Sep 30)
    |
    | My problem is this causes all backup and maintenance tasks scheduled
    | not to run.
    |
    | What does scosh cronsched -r and scosh cronsched -wr do?
    | I can find no doentation for cronsched.
     

    The cronsched entry in cron is used by the system to generate
    the calendar files requested by users option settings.
    The "r" means: add a random time variation to the time setting
    so that every machine does not try to access the calendar server
    at the same time.
    The "w" means weekly instead of daily.

    | If I run it after setting the date, will it reschedule the cron jobs?

    No.


    --
    JP
    Jean-Pierre Guest

  3. #3

    Default Re: Changing Date Results in Cron Jobs not Running


    "Peter McGill" <net> wrote in message
    news:allstream.net... 

    Check your user's manual for this accounting package. I know of no
    accounting systems that rely strictly on the system date for the
    module posting date. In fact, most systems have a separate posting
    date for each and every accounting module (A/P, A/R, P/R, etc.)
    allowing you to backdate postings as far as the last time you closed
    out that particular module.

    You should never have to reset the system date to accomplish this.

    Bob


    Bob Guest

  4. #4

    Default Re: Changing Date Results in Cron Jobs not Running

    Peter McGill wrote:
     

    You can get them to run by restarting cron. To do this, as root, run:

    /etc/rc2.d/P75cron stop
    rm -f /usr/lib/cron/FIFO
    sd cron

    Whether this is actually a good idea is up to you. It will rerun Sep 30
    cron jobs. If you have a rotating backup schedule (doing full backups
    some days and incrementals other days) it will do whatever it was
    supposed to do on Sep 30, repeatedly. Depending on how your backup
    procedure works, this could be no big deal or it could be disastrous.
     
    Bela Guest

  5. #5

    Default Re: Changing Date Results in Cron Jobs not Running

    On Tue, 07 Oct 2003 19:20:31 GMT, "Bob Bailin"
    <com> wrote:
     
    >
    >Check your user's manual for this accounting package. I know of no
    >accounting systems that rely strictly on the system date for the
    >module posting date. In fact, most systems have a separate posting
    >date for each and every accounting module (A/P, A/R, P/R, etc.)
    >allowing you to backdate postings as far as the last time you closed
    >out that particular module.
    >
    >You should never have to reset the system date to accomplish this.
    >
    >Bob
    >
    >[/ref]

    Actually it is custom accounting software, I've told them it should be
    rewriten, so the software, defaults the date to sep 30 at year end
    instead of the current computer date. This is all because the users
    forget to type in sep 30 and just accept the date given to them.
    *rolls eyes*
    Anyway I just need to get through this year turn, by next year it
    should be rewritten.

    Peter

    pamcgill@rogers.com Guest

  6. #6

    Default Re: Changing Date Results in Cron Jobs not Running

    On Tue, 7 Oct 2003 19:30:33 GMT, Bela Lubkin <com> wrote:
     
    >
    >You can get them to run by restarting cron. To do this, as root, run:
    >
    > /etc/rc2.d/P75cron stop
    > rm -f /usr/lib/cron/FIFO
    > sd cron
    >
    >Whether this is actually a good idea is up to you. It will rerun Sep 30
    >cron jobs. If you have a rotating backup schedule (doing full backups
    >some days and incrementals other days) it will do whatever it was
    >supposed to do on Sep 30, repeatedly. Depending on how your backup
    >procedure works, this could be no big deal or it could be disastrous.
    > [/ref]

    Not a problem for my backup scripts. My crontab looks something like
    this: (I'm at home now, so I'm just going to summarize)

    10pm reset date to correct date from date saved in file
    Then run other backup and maintenance scripts...
    At 6am save correct date to file, and set date to sep 30

    Can I reset cron from within a cron job or will that be a problem, if
    so I could append it to the date change script, which would be
    perfect.

    Peter

    pamcgill@rogers.com Guest

  7. #7

    Default Re: Changing Date Results in Cron Jobs not Running

    com wrote: 
     [/ref]
     

    Well, I solved a problem similar to that with Expect:
    You stuff Sep 30th into the appropriate place and then return
    control to the user..

    --
    com Unix/Linux/Mac OS X resources: http://aplawrence.com
    Get paid for writing about tech: http://aplawrence.com/publish.html
    tony@aplawrence.com Guest

  8. #8

    Default Re: Changing Date Results in Cron Jobs not Running

    Peter McGill wrote:

    Peter>>> When our company turns the year, they want me to reset the date back
    Peter>>> to Sep 30 each day until we have finished all accounting for that
    Peter>>> year. Stupid I know. (Our year is Oct 1 - Sep 30)

    Peter>>> My problem is this causes all backup and maintenance tasks scheduled
    Peter>>> not to run.

    Bela>> You can get them to run by restarting cron. To do this, as root, run:

    Bela>> /etc/rc2.d/P75cron stop
    Bela>> rm -f /usr/lib/cron/FIFO
    Bela>> sd cron

    Bela>> Whether this is actually a good idea is up to you. It will rerun Sep 30
    Bela>> cron jobs. If you have a rotating backup schedule (doing full backups
    Bela>> some days and incrementals other days) it will do whatever it was
    Bela>> supposed to do on Sep 30, repeatedly. Depending on how your backup
    Bela>> procedure works, this could be no big deal or it could be disastrous.

    Peter> Not a problem for my backup scripts. My crontab looks something like
    Peter> this: (I'm at home now, so I'm just going to summarize)

    Peter> 10pm reset date to correct date from date saved in file
    Peter> Then run other backup and maintenance scripts...
    Peter> At 6am save correct date to file, and set date to sep 30

    Peter> Can I reset cron from within a cron job or will that be a problem, if
    Peter> so I could append it to the date change script, which would be
    Peter> perfect.

    I've never tried stopping and restarting cron from within a cron job.
    It might work perfectly smoothly; I expect that if it did not, the
    failure would be obvious. (The most likely failure mode would be that
    when you killed cron, on its way down it would kill all of the jobs it
    started, thus aborting the script that was about to restart it.)

    So, don't know, but it should be safe for you to test (and then please
    report back...)

    BTW, adding it to the date-change script wouldn't make any difference,
    if I understand what you said. You must be running that date-change
    script from a cron job, so the same issues would apply.
     
    Bela Guest

  9. #9

    Default Re: Changing Date Results in Cron Jobs not Running

    On Wed, 8 Oct 2003 07:31:34 GMT, Bela Lubkin <com> wrote: [/ref]

    Yes that's what I meant the date change script is a cron job.

    I'll test it out and let you know how it goes.

    Peter

    Peter Guest

  10. #10

    Default Re: Changing Date Results in Cron Jobs not Running

    On Thu, 09 Oct 2003 03:28:18 GMT, com (Peter McGill)
    wrote: 

    Here is my test results:

    Test 1 Setup:

    /usr/backup/setdate.sh -s YYYYMMDD
    Saves system date to file, changes system date to YYYYMMDD, does not
    affect time.
    Runs /usr/backup/resetcron.sh

    /usr/backup/setdate.sh -u
    Reads date from file, and changes system date to date from file, does
    not affect time.
    Runs /usr/backup/resetcron.sh

    /usr/backup/resetcron.sh:
    #!/bin/sh
    /etc/rc2.d/P75cron stop
    rm -f /usr/lib/cron/FIFO
    #sd cron
    /etc/rc2.d/P75cron start
    exit 0

    crontab:
    25 14 * * * /usr/backup/setdate.sh -s 20030930
    30 14 * * * /usr/backup/setdate.sh -u

    Test 1 Results:

    At 2:25 pm date changes to Sep 30, cron does not get shutdown, but new
    cron starts, now have 2 crons. Results of stdout are mailed.

    At 2:30 pm date restored to Sep 9, cron(s) do not get shutdown, but
    new cron(s) start, now have 4 crons. Duplicate Results of stdout are
    mailed (1 from each cron, job ran twice).

    Test considered a failure, all cron(s), manually killed and new cron
    started.

    I got an idea from crontab -e command and something I've done with vi
    in the past.

    Test 2 Setup:

    /usr/backup/setdate.sh -s YYYYMMDD
    Same as before, but now Runs /usr/backup/rereadcrontab.sh instead.

    /usr/backup/setdate.sh -u
    Same as before, but now Runs /usr/backup/rereadcrontab.sh instead.

    /usr/backup/setdate.sh -r
    Displays the true date, even if its been altered, does not affect the
    date or cron.

    /usr/backup/rereadcrontab.sh:
    #!/bin/sh
    crontab -e <<END > /dev/null
    :wq
    END
    exit 0

    crontab:
    40 14 * * * /usr/backup/setdate.sh -s 20030930
    45 14 * * * /usr/backup/setdate.sh -u
    50 14 * * * /usr/backup/setdate.sh -r

    Test 2 Results:

    At 2:40 pm date is changed to Sep 30. Results of stdout are mailed.

    At 2:45 pm date is restored to Oct 9. Results of stdout are mailed.

    At 2:50 pm. Results are stdout is mailed.

    Test considered a success!
    Crontab returned to normal, and appropriate changes commited to
    scrips.

    Thanks guys.

    Peter McGill

    Peter Guest

  11. #11

    Default Re: Changing Date Results in Cron Jobs not Running

    Peter McGill wrote:
     

    Everything else past this point is going to be bad. If cron didn't shut
    down, you need to discover why and fix that. A 2nd cron wouldn't have
    started up if /usr/lib/cron/FIFO hadn't been removed; the multiple
    cron's are due not only to the failed shutdown, but also a failure to
    recognize it as a failed shutdown.

    The shutdown code in /etc/rc2.d/P75cron is fairly simple, you should be
    able to run it as `sh -x /etc/rc2.d/P75cron stop` and get some idea of
    why it doesn't stop.
     

    Hmmm, so that's an automated execution of `vi` in order to touch a file
    and remind cron about it. Which you are doing for the apparent side
    effect of getting cron to reconsider the jobs relative to the _current_
    time rather than what time cron thought it was.
     

    It looks like what you've done will work, but I'm not sure overall how
    trustworthy it is. For instance, when cron reconsiders root's crontab
    due to the `crontab -e` stuff, does it reconsider _all_ users' crontabs,
    or only root's?

    Even though it's more brute force, I think the kill/restart method is
    probably safer. You just need to figure out why it doesn't shutdown on
    demand.
     
    Bela Guest

  12. #12

    Default Re: Changing Date Results in Cron Jobs not Running

    On Fri, 10 Oct 2003 18:29:36 GMT, Bela Lubkin <com> wrote:
     
    >
    >Everything else past this point is going to be bad. If cron didn't shut
    >down, you need to discover why and fix that. A 2nd cron wouldn't have
    >started up if /usr/lib/cron/FIFO hadn't been removed; the multiple
    >cron's are due not only to the failed shutdown, but also a failure to
    >recognize it as a failed shutdown.
    >
    >The shutdown code in /etc/rc2.d/P75cron is fairly simple, you should be
    >able to run it as `sh -x /etc/rc2.d/P75cron stop` and get some idea of
    >why it doesn't stop.

    >
    >Hmmm, so that's an automated execution of `vi` in order to touch a file
    >and remind cron about it. Which you are doing for the apparent side
    >effect of getting cron to reconsider the jobs relative to the _current_
    >time rather than what time cron thought it was.

    >
    >It looks like what you've done will work, but I'm not sure overall how
    >trustworthy it is. For instance, when cron reconsiders root's crontab
    >due to the `crontab -e` stuff, does it reconsider _all_ users' crontabs,
    >or only root's?
    >
    >Even though it's more brute force, I think the kill/restart method is
    >probably safer. You just need to figure out why it doesn't shutdown on
    >demand.
    > [/ref]

    Noted. Although if I remember correctly (at home again), there are
    only 3 crontabs on our system. root, uucp, and one for my user
    account. uucp I don't much care about since we don't use it, and mine
    I could always put in root, I haven't as yet because it really doesn't
    need to be run as root. Another possibility is using find to determine
    what crontabs there are and sending that to a loop to reread all of
    them.

    Of course fixing the restart would be good too, I tried the script
    from the console as well and it reacted the same, so it's not as a
    result of being run from within a cron job.

    Although, it seems safer to me to reread the crontab(s), since you
    don't have to worry about the possibility of a job not finishing, or
    the results not being mailed when the cron is killed.

    Peter

    Peter Guest

  13. #13

    Default Re: Changing Date Results in Cron Jobs not Running

    In article <3f8806bc.682172nntp>, Peter McGill <com> wrote: 
    >>
    >>Everything else past this point is going to be bad. If cron didn't shut
    >>down, you need to discover why and fix that. A 2nd cron wouldn't have
    >>started up if /usr/lib/cron/FIFO hadn't been removed; the multiple
    >>cron's are due not only to the failed shutdown, but also a failure to
    >>recognize it as a failed shutdown.
    >>
    >>The shutdown code in /etc/rc2.d/P75cron is fairly simple, you should be
    >>able to run it as `sh -x /etc/rc2.d/P75cron stop` and get some idea of
    >>why it doesn't stop.
    >> 
    >>
    >>Hmmm, so that's an automated execution of `vi` in order to touch a file
    >>and remind cron about it. Which you are doing for the apparent side
    >>effect of getting cron to reconsider the jobs relative to the _current_
    >>time rather than what time cron thought it was.
    >> 
    >>
    >>It looks like what you've done will work, but I'm not sure overall how
    >>trustworthy it is. For instance, when cron reconsiders root's crontab
    >>due to the `crontab -e` stuff, does it reconsider _all_ users' crontabs,
    >>or only root's?
    >>
    >>Even though it's more brute force, I think the kill/restart method is
    >>probably safer. You just need to figure out why it doesn't shutdown on
    >>demand.[/ref][/ref]
     
     
     

    Just an off the wall thinking on this, what about modifying the
    shutdown so the system automatically restarts and reboot - but
    as one of the last things you do, update the hardware clock
    by setting things back one day.

    You realize that when you do set the date backwards there will be
    files in the system which will be in the future and and sometimes
    those totally confuse a system if anything depends on time stamps.

    And make sure that the dates don't accidentally get set wrong
    if you are entering them manually. I saw one system almost fall
    over when someone spotted the fact that they had entered the wrong
    year and so re-entered the date. At that point cron started
    processing the thousands of jobs it had not done in the intervening
    year - as some thing run ever 5 minutes. Things were decidedly
    slow until cron caught up.


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

Similar Threads

  1. CF Scheduler jobs not running
    By Master Jefa in forum Coldfusion Server Administration
    Replies: 2
    Last Post: October 2nd, 02:53 AM
  2. cPanelX - Cron Jobs
    By pokeronald in forum PHP Development
    Replies: 2
    Last Post: May 21st, 10:45 PM
  3. Cron jobs and perl
    By Trina Espinoza in forum PERL Beginners
    Replies: 18
    Last Post: August 29th, 10:11 PM
  4. cron may not be running = HELP
    By The_Duck in forum Sun Solaris
    Replies: 2
    Last Post: August 25th, 10:29 PM
  5. Replies: 1
    Last Post: July 27th, 04:28 PM

Bookmarks

Posting Permissions

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139