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