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
jp@tygra.UUCP (John Palmer) (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. 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. > HA! You're lucky. You have SCO UNIX! We XENIX people have to put up with cron stopping altogether. It gets messed up by the switch to EDT and just stops working. The cron process doesn't die or print any error message, it just sits there looking stupid. Oh, and XENIX cron doesn't respond to SIGHUP by reading the cron files again. If you update anything in /usr/spool/cron/crontabs, you have to kill the current cron and start a new one. Maybe SCO should fix this. -- CAT-TALK Conferencing System | "Buster Bunny is an abused | E-MAIL: +1 313 343 0800 (USR HST) | child. Trust me - I'm a | jp@tygra.UUCP +1 313 343 2925 (TELEBIT PEP) | professional..." | ..sharkey!tygra! ********EIGHT NODES*********** | -- Roger Rabbit | ..jp
n025fc@tamuts.tamu.edu (Kevin Weller) (04/10/91)
In article <1991Apr9.073715.8969@tygra.UUCP> jp@tygra.UUCP (John Palmer) writes: > > HA! You're lucky. You have SCO UNIX! We XENIX people have to put up > with cron stopping altogether. It gets messed up by the switch to > EDT and just stops working. The cron process doesn't die or print any > error message, it just sits there looking stupid. Hmmm... guess you're just lucky. :-) My system adjusts the time properly, with no hang-ups, so it must not be a universal problem. It may be a problem with the interaction of the software with your clock hardware? -- ------------------------------------------------------------------------------ Kevin L. Weller /-------+--------------------\ internet: n025fc@tamuts.tamu.edu | aTm | GIG 'EM, AGGIES! | CIS: 73327,1447 (but I rarely log on) \-------+--------------------/ ------------------------------------------------------------------------------ %SYS-E-BADOPSYS, Fatal system error, DEC VMS halting / "And now for something -SYS-I-GETUNIX, Replace with UNIX immediately! / completely different." ----------------------------------------------------------------- Monty Python
n025fc@tamuts.tamu.edu (Kevin Weller) (04/10/91)
OOPS! Forgot to specify that I'm using XENIX 2.3.3. Sorry! -- ------------------------------------------------------------------------------ Kevin L. Weller /-------+--------------------\ internet: n025fc@tamuts.tamu.edu | aTm | GIG 'EM, AGGIES! | CIS: 73327,1447 (but I rarely log on) \-------+--------------------/ ------------------------------------------------------------------------------ %SYS-E-BADOPSYS, Fatal system error, DEC VMS halting / "And now for something -SYS-I-GETUNIX, Replace with UNIX immediately! / completely different." ----------------------------------------------------------------- Monty Python
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
srodawa@vela.acs.oakland.edu (Ron Srodawa) (04/11/91)
I reported a bit ago my time went forward TWO hours. Problem solved! I am running timed. Also running timed is an old 4.3BSD system. It changes from standard time to daylight time on the wrong day, a month from now. A systems programmer set the clock ahead an hour so the numbers would be correct even though the designation was standard time. Of course, this caused systems running timed slaves to try and synch with that clock. That systems UTS was an hour ahead of the real UTS. Ron. -- | Ronald J. Srodawa | Internet: srodawa@vela.oakland.edu | | School of Engineering and CS | UUCP: srodawa@vela.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
tkevans@fallst.UUCP (Tim Evans) (04/11/91)
In <1991Apr9.073715.8969@tygra.UUCP> jp@tygra.UUCP (John Palmer) writes: >Oh, and XENIX cron doesn't respond to SIGHUP by reading the cron files >again. If you update anything in /usr/spool/cron/crontabs, you have to >kill the current cron and start a new one. Maybe SCO should fix this. Don't tell me you're directly editing the files in /usr/spool/cron/crontabs! Do this, to be safe, and to make cron re-read the changes you make: o crontab -l > tempfile o edit 'tempfile' to enter your cron changes o crontab tempfile -- UUCP: {rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans INTERNET: tkevans%fallst@wb3ffv.ampr.org Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047
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!
sginn@hlthnt.UUCP (Steve Ginn) (04/13/91)
I know that this really has nothing to do with the above mentioned problems associated with Subject: but since it has to do with system time I will go ahead anyway. Under DOS, there is available, a shareware program called TIMESET which allows you to just run timeset which calls up to the Naval Observatory automatically and then does a count down and finally resets that actual system time precisely (to the second) with the Naval Observatory atomic clock. Does anyone know if this same type of program might be available for Xenix? It seems to me that this would be an even handier application for Xenix/Unix to use with cron in the background so as to always keep very accurate time on the system! Thanks, Steve Ginn