scott@phlpa.UUCP (Scott Scheingold) (04/08/91)
I have noticed that some of my cron jobs are running an hour later than they are normally run. Example uucp.cleanup is supposed to run at 23:45 but it is running at 00:45 instead. This has occured since the swich to EDT. The system swiched the time on sunday just like we would change the clocks automaticly. Now not all the jobs are running late just some. Have I come across a bug with SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should do to get things back on track (besides a reboot of the system). I was supprised when I found the clock had changed. I am just glad that I didn't have anything of real importance that needed to be run at a specific time. My next question would be when we switch back to EST will this become a problem once again. Just wondering, Scott Scheingold E-mail ...!lgnp1!phlpa!scott
rvdp@cs.vu.nl (Ronald van der Pol) (04/09/91)
>I have noticed that some of my cron jobs are running an hour later >than they are normally run. Example uucp.cleanup is supposed to >run at 23:45 but it is running at 00:45 instead. This has occured >since the swich to EDT. The system swiched the time on sunday >just like we would change the clocks automaticly. Now not all the >jobs are running late just some. Have I come across a bug with >SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: - it is 14:15 MET DST at the moment - 'date' says it is 13:15 MET - localtime(3) says it is 18:15 MET - our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' What is going on here?? -- Ronald van der Pol <rvdp@cs.vu.nl>
les@chinet.chi.il.us (Leslie Mikesell) (04/09/91)
In article <9@phlpa.UUCP> scott@phlpa.UUCP (Scott Scheingold) writes: >I have noticed that some of my cron jobs are running an hour later >than they are normally run. > Have I come across a bug with >SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should >do to get things back on track (besides a reboot of the system). It happens on AT&T's 3B2 SysVr3.2 so it it probably a generic sysV bug. If you kill and restart cron everything should go back to normal, at least if the process doing the restarting was logged in after the switch to DST. >I was supprised when I found the clock had changed. I am just glad >that I didn't have anything of real importance that needed to be >run at a specific time. The fact that this bug has been allowed to remain and so few people seemed to notice makes me wonder if anyone is doing anything of real importance with sysV unix. >My next question would be when we switch >back to EST will this become a problem once again. No, that one is worse - at least on the 3B2's SysVr3.1 it runs everything in the crontab twice on the day after the switch. After losing some important logfiles to this, I've taken to turning off DST before the switch in the fall, then resetting it manually the next day to make sure the running cron is killed (so I don't know if it is still a problem in r3.2). Les Mikesell les@chinet.chi.il.us
pinkas@st860.intel.com (Israel Pinkas) (04/10/91)
In article <9@phlpa.UUCP> scott@phlpa.UUCP (Scott Scheingold) writes: > I have noticed that some of my cron jobs are running an hour later > than they are normally run. Example uucp.cleanup is supposed to > run at 23:45 but it is running at 00:45 instead. This has occured > since the swich to EDT. The system swiched the time on sunday > just like we would change the clocks automaticly. Now not all the > jobs are running late just some. Have I come across a bug with > SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should > do to get things back on track (besides a reboot of the system). > I was supprised when I found the clock had changed. I am just glad > that I didn't have anything of real importance that needed to be > run at a specific time. My next question would be when we switch > back to EST will this become a problem once again. This problem is a basic result of the PC style architecture. (However, AT&T could have solved this in software.) The PC architecture's battery powered clock stores the date and time (year, month, day, hours, minutes, seconds). Most other architectures just have a counter that counts seconds or clock ticks. When Unix (SysV, but this may also apply to BSD and Mach) boots, a program called setclk reads the hardware clock and sets the CMOS counter for the kernel. The timer interupt handler keeps the CMOS counter updated. (Some variations of the PC maintain the CMOS counter without software intervention.) The CMOS counter stores Unix time, which is the number of seconds since 12:00 am, Jan 1, 1970 GMT. This is the time that most systems maintain in the battery powered clock. As long as a PC is on, the system knows the true time. When the switch to DT occurs, and the TZ environment variable is set, date (and all the library routines) report the time in DT. However, when the system is rebooted, the hardware clock is read, and setclk believes the battery powered clock. Since it is DT, setclk assumes that the time is in DT. The assumption is that since the system could be booted in DOS, the user might have set the battery powered clock from DOS to DT. Lousy assumption, IMO. The quick and easy solution is to set the date as soon as possible after the clock changes. date sets the batter powered clock. The correct solution to the problem is to modify setclk to assume that the battery powered clock is always on standard time. This is probably a more reasonable assumption for two reasons: (1) most people do not switch their systems between DOS and Unix very often, and (2) many DOS users leave their system on ST all year, BECAUSE DOS has no concept of DT. (Blame IBM and Microsoft for that.) If you do this, you will need to make changes in your kernel so that the date command sets the battery powered clock on standard time. Another alternative, if you leave your system up all the time is to have a cron entry like this: 0 3 * 4,10 0 "date `date +%m%d%H%M`" date sets the battery powered clock (as a side effect). This crontab entry sets the date and time to the current date and time at 3 am every Sunday in April and October. Since the time date reports is correct right after the switch to and from DT, this should work. Your mileage may vary, and you may have to change the format for date. A third way of doing this (if you don't have source) would be to run a script from either the crontab or the at queue (resubmitting itself) that advanced the clock one hour in the spring and set the clock back in the autumn. Care should be taken that the script can only work once, and that it correctly determines whether the time date reports is off by an hour. (Looking at the system uptime would be one way.) If you run rdate, you should not run the daemon on SysV/386 machines, as they will mess up the network time. You could make them update from the network, though. Hope this helps. -Israel Pinkas -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas ARPA: pinkas%st860.intel.com@relay.cs.net CSNET: pinkas@st860.intel.com
chris@ukelele.UUCP (Chris Linstruth) (04/11/91)
pinkas@st860.intel.com (Israel Pinkas) writes: > >In article <9@phlpa.UUCP> scott@phlpa.UUCP (Scott Scheingold) writes: > >> I have noticed that some of my cron jobs are running an hour later >> than they are normally run. Example uucp.cleanup is supposed to >> .. stuff deleted .. >> run at a specific time. My next question would be when we switch >> back to EST will this become a problem once again. > >This problem is a basic result of the PC style architecture. (However, >AT&T could have solved this in software.) > >The PC architecture's battery powered clock stores the date and time (year, >month, day, hours, minutes, seconds). Most other architectures just have a >counter that counts seconds or clock ticks. > >... makes some valuable suggestions ... I dealt with this problem by setting the hardware clock to GMT and setting the system clock at boot time with: : # @(#)bsetdate.sh 1.1 TZ=GMT0;export TZ date `/etc/setup -d` > /dev/null . /etc/TIMEZONE echo "System time: \c" date setup -d outputs the CMOS clock setting in a date(1) parsable format. This is on uPort V/AT and Daylight to Standard time switches have been automatic and effortless for two years. cron even seems to be executing jobs at the appropriate times. -- Chris Linstruth ____ ___ The Genuine Aloha Ukelele chris@ukelele.UUCP / \_/ \______OO (703) 960-8428 * 4 {uunet, rutgers}!mimsy - | (_) ______## 2400/1200 N-8-1 !prometheus!ukelele!chris \____/ \___/ OO UNIX For The Masses!
alan@ukpoit.co.uk (Alan Barclay) (04/11/91)
In article <1991Apr09.162130.1479@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <9@phlpa.UUCP> scott@phlpa.UUCP (Scott Scheingold) writes: >>I have noticed that some of my cron jobs are running an hour later >>than they are normally run. >>run at a specific time. > >The fact that this bug has been allowed to remain and so few people >seemed to notice makes me wonder if anyone is doing anything of >real importance with sysV unix. From the man page on my system (NCR tower running V.2), /* Start of retyped quote */ RESTRICTIONS With the introduction of the new database timezone utilities, the user can tailor the date/hour on which daylight savings time occcurs. Whenever a change is made, cron must be restarted, and jobs performed on the first day of the chage are run one hour later than expected. Job performed on subsequent days are then run as expected. /* End of retyped quote */ Therefore somebody knew about it. We get round it by killing cron, just like TFM says. -- Alan Barclay iT | E-mail : alan@ukpoit.uucp Barker Lane | BANG-STYLE : .....!ukc!ukpoit!alan CHESTERFIELD S40 1DY | VOICE : +44 246 214241
torek@elf.ee.lbl.gov (Chris Torek) (04/13/91)
In article <295@ukelele.UUCP> chris@ukelele.UUCP (Chris Linstruth) writes: >I dealt with this problem by setting the hardware clock to GMT ... The is the right way to do it. Another method that is not quite as good, but might be necessary for some people, is to keep the hardware clock on `normal' time: instead of >TZ=GMT0;export TZ >date `/etc/setup -d` > /dev/null >. /etc/TIMEZONE you could (assuming your timezone is EST5EDT, e.g.) use TZ=EST5 date `/etc/setup -d` >/dev/null TZ=EST5EDT; export TZ It is (or will lead to :-) ) sheer insanity to keep internal times in multiple formats, and it is best to use a single agreed international standard for internal times so that all machines can agree as to what time it is. (It is somewhat amusing to watch PC users bump into all the old problems as their systems expand. I imagine old-timers felt the same way about Unix systems when they began to displace `mainframes'.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
gwyn@smoke.brl.mil (Doug Gwyn) (04/16/91)
In article <1991Apr09.162130.1479@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <9@phlpa.UUCP> scott@phlpa.UUCP (Scott Scheingold) writes: >>I was supprised when I found the clock had changed. ... Me too -- the UNIX kernel clock does NOT need resetting to accommodate DST.