Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Managing Batch Jobs for Several Time Zones? 44

Posted by Cliff from the midnight-run dept.
sporty asks: "I have one machine, a unix box, that serves many time zones at once. Because of this, everything is stored in GMT. Even the system clock is set relative to GMT. The problem is determining when midnite is. I need to run certain jobs, via cron or similar, so that something runs at midnite in that timezone. Anyone have this situation before?"
This discussion has been archived. No new comments can be posted.

Managing Batch Jobs for Several Time Zones? More

Managing Batch Jobs for Several Time Zones?

Comments Filter:

  • Not enough information (Score:5, Interesting)

    by mcdrewski42 ( 623680 ) on Tuesday July 22, 2003 @02:58AM (#6497202)
    One unix box. Multiple timezones. Evidently a different script needs to be run for each timezone, since otherwise you'd just run your script every half hour on the half hour...

    Why not set up a set of groups with defined IDs (say maybe 1000 - 1047) for each timezone. Allocate users in the appropriate timezone to those groups

    Run a master script every hour (or half hour) which su's to a dummy member of that group and runs some script. you get some protection from accidentally breaking things by running as root.

    Care to tell us exactly what the obvious solutions don't do? what you're trying to do maybe?
    • Right now, the time zone I'm in respects daylight savings. Midnite is gonna shift in the fall, as well as in april. Places like england or or barbados celebrate it at different times or not at all.

      Writing a job managing job on top of a job managing job (at on cron) could get messy. Especially so when day light savings hits for various places.
      • My point is, you can assume that every hour on the hour of every day it is midnight somewhere. Additionally you have some weird timezones on the half hour too. The timezone your machine is in is GMT (UTC). It does not have timezones.

        What sort of thing is it that needs to be done every half hour of every day on the one unix box?

        I assume that you have a bunch of users, each of whom is assumed to be in a given timezone. You need to do something for each user at midnight in their timezone and you're worrie
  • -Find out what the GMT offset for each time zone is.
    -Use that to figure out what GMT time is midnight for each time zone.
    -Make a cron job for each time zone to run when it is midnight in that time zone.

    Unless there is something about the question I don't understand...?
    • Because the clock offsets change, and change at different times for different timezones... I presume you want to avoid going through a list of timezones once a week and adjusting the jobs :(
      • GMT offsets don't change THAT often. Not in the U.S., anyways. And we're left to ASSUME those are the only timezones he is referring to since this is a U.S.-centric site. :P

        Plus, you could write a script to change your scripts. Or something.
        • Nope, I'm dealing with worldwide timezones. If it were simple as puttin in the crontab, run at midnite GMT or midnite, EDT5EST (I've seen that somewhere), that'd pwn. Problem is, cron doesn't support that. Well.. not yet if I don't find an easier solution than "fixing' cron in c.

          • update your crontab every night at one AM for the next date (see below). You just need a script called getmidnight.sh that returns the local hour for GMT midnight. I bet DateTime.pm could do this.

            ## /etc/crontab.template
            1 0 0 0 0 /usr/bin/update_cron.sh
            MIDNIGHT 0 0 0 0 0 /usr/bin/midnight_script.sh

            ## /usr/bin/update_cron.sh
            sed s/MIDNIGHT/`getmidnight.sh`/ /tmp/crontab
            crontab -l /tmp/crontab
        • GMT offsets don't change THAT often.

          Ya, they don't change that often, but the problem is that some (even in the US) don't change (like Arizona or places nearer to the equator) ever. Others change at different times of the year (daylight savings time begins in most Western European countries a week before it does in North America) or in different directions (ie, southern hemisphere summer is northern hemisphere winter). These things would just make it a pain.

          It seems like you could run some cron job ev

      • #!/bin/sh
        do-my-job
        at midnight "$0" # or TZ=GMT at midnight "$0" for running at 00:00GMT regardless of local time

        ...should cope with DST changes, I think...? Slightly more of a faff to cancel, though.

        (E&OE ;-)

  • Please, geeks of the world (Score:5, Informative)

    by Anonymous Cowdog ( 154277 ) on Tuesday July 22, 2003 @03:38AM (#6497319) Journal
    Don't know if this advice applies to this guy or not, because he might truly have a need to run at exactly midnight. But please, run your cron jobs at randomly chosen times, instead of exactly on the hour. That way we can spread the load (machine and network) better. Thank you, have a nice day.
  • For each time zone, there's only going to be certain GMT times that can be "local" midnight. (Usually two.) So, at those times, you run a script that checks the "local" time, and, if it is actually midnight, runs the job! Simple, clean, sweet.

    There's a tiny amount of overhead for running the check script at times that aren't local midnight, but that should be completely negligible.
    • Sounds like I'd put a custom cron on top of cron. It'd work nicely in the short term. I might as well "fix" vixie cron to respect my GMT autoritah.

      I forsee myself having to do stuff at 3pm GMT or 1pm EDT or 2pm MDT.
      • Sounds like I'd put a custom cron on top of cron.

        No, just a simple test:
        #!/bin/sh
        if [ $(TZ=$1 date +%H) = 0 ]
        then run_my_job
        fi

    • correction... (Score:4, Informative)

      by Xtifr ( 1323 ) on Tuesday July 22, 2003 @05:36PM (#6504689) Homepage
      I just noticed that there's a bug in that approach. On days when the time changes, you might end up running the job twice or not at all.

      However, there's another simple solution. Again, based on the fact that there's really only two times that can be local midnight. Simply run a script like this at the earlier of the two times:
      if [ $(TZ=$1 date +%H) = 23 ]; then # it's 11pm in timezone $1
      sleep 1h # wait till midnight
      # (on some systems, you might need "sleep 3600")
      fi
      run_my_midnight_task
      Note that hacking cron to respect timezones will result in the same bug as my earlier approach. So, this approach is really the cleanest I can see.
      • I like the solution. Too bad i'm gonna have to write a script between each process and cron. well.. tnx.

        -s
        • Too bad i'm gonna have to write a script between each process and cron

          No, that's why I made the time zone an argument to the script. So, in the crontab, you just pass the appropriate zone name when you call the script.
  • Never heard of it.
  • Offtopic:

    You may want to consider your use of midnight as a good time to run scripts.

    Many people are still awake at this time, perhaps working from home, trying to beat a deadline, etc. Cron jobs using resources at this time could be frusturating, making a long night even longer.

    You may want to consider moving jobs to 2 or 3 AM instead.

  • TZ is your friend (Score:5, Informative)

    by sysadmn ( 29788 ) <{sysadmn} {at} {gmail.com}> on Tuesday July 22, 2003 @07:46AM (#6497986) Homepage
    Fun Facts:
    • The TZ environment variable is used to determine how to interpret times.
    • Most shells allow you to set environment variables for a single command by specifying them on the command line

    i.e.
    $ TZ=EST5EDT at 12 am

    ...
    $ TZ=PST8PDT at 12 am
    ...
    $ at -l
    1058932800.a Wed Jul 23 00:00:00 2003
    1058943600.a Wed Jul 23 03:00:00 2003
    • Yeah, but problem is, it happens in a cron-like fashion. Midnite every nite forever and ever. With timezone shifts for day light savings, it's not a static number.

      I can have cron do a job way before midnite, but if I had to have a job run in all 24 time zones, it could get ugly in running many at jobs at many times.

      It'd be great if there was somethign clean to put in cron as...

      0 0EDT * * * ....

      I might have to write that a day.
      • The problem with hacking cron to respect local time is that in local time, there is (once a year) a day with two midnights, and a day with none.

        I think the best approach is the one I outlined here [slashdot.org]. Run at the earliest time that might be midnight, and if it's not yet midnight, sleep till it is.
  • Just remember that when you have them run for each time zone, there is a thing called Daylight Savings Time in some time zones, and not in others. Depending on where your facilities might be, there are some places in Nevada for example that are in a Daylight Savings Time area, and other parts that are not. Just remember to offset those by an hour when DST occurs and when it goes back to normal time.
    • This is true even of some states! During EST, Indiana is the same as the rest of the Eastern Time Zone. When the rest of the Eastern Time Zone switches to EDT, Indiana is still on EST. I think Arizona is like this also (most of year it matches Colorado's time, but when Colorado springs forward, Arizona does not.)

      I might also add that Midnight isn't as late as it used to be. Push cron jobs past midnight by an hour or two. System could still be busy at midnight depending on the place you work at. At a
  • I'd create a virtual-server for each timezone in question, it could have its own ntp tools managing the time, and its own cron to be the timer. Keep things nice and neat. In freebssd at least this could be done in a jail.
    • I think you just need an ordinary chroot, and there's no need for separate NTP daemons. In each chroot, you have a separate /var/cron/tabs to store the crontabs for that TZ, and a separate /etc/localtime to specify the TZ. Then you run a cron in each chroot.

      This approach assumes that the tasks you want to perform are practical inside a chroot or jail.

  • DateTime.pm is your friend (Score:4, Informative)

    by Space_Nerd ( 255762 ) on Tuesday July 22, 2003 @11:47AM (#6499902)
    Check it out, it converts between timezones automagically, respects daylight savings, and all of the fun stuff.

    It's really a lifesaver, here is a link DateTime.pm [cpan.org]
  • We have a similar problem and right now we are working on modifying the code for cron (vixie derived) to allow us to run multiple instances each with a different timezone. It's not a top priority for us but will post it somewhere, when it's done.
  • Rather than trying to make cron do something it doesn't want to (which obviously won't work in this situation without modifying cron, not a good idea if you rely on it for other things), write a tiny program that does nothing more than load a list of GMT times at which it needs to do something, and executes a script associated with that time.

    You'd need only one main config file, looking something like:
    00:00 script.ut
    16:00 script.pmt
    19:00 script.edt
    (blah, blah, blah)

    And each individual script could h
  • The problem is determining when midnite is.

    Seems to me that the real problem is determining how to spell midnight. 8)
  • This problem was solved by NQS (Network Queueing System) a long time ago. They have a date parsing routine that knows about timezones. You can either use NQS itself, or rip the date parser out of it. In any case, it allows you to specify, literally, "midnight EDT" as a time to run a job.
    NQS code should be available on the net - the source was released by NASA a long time ago.

Slashdot Top Deals

"It's a dog-eat-dog world out there, and I'm wearing Milkbone underware." -- Norm, from _Cheers_

Close