les@chinet.chi.il.us (Leslie Mikesell) (11/05/88)
Our 3B2's running sysVr3.1 ran all the crontab entries twice after the change from DST. I kind of expected that for the entries between 1 and 2 AM, but the subsequent entries also ran twice. Is this normal? Is it fixed in SysVr3? I lost an important log file when the end of the month happened twice. Les Mikesell
john@ziggy.UUCP (John Mullins) (11/06/88)
In article <6896@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Our 3B2's running sysVr3.1 ran all the crontab entries twice after >the change from DST. I kind of expected that for the entries between >1 and 2 AM, but the subsequent entries also ran twice. Is this >normal? Is it fixed in SysVr3? I lost an important log file when >the end of the month happened twice. > >Les Mikesell This is "normal" for AT&T sysVr3.1 . It also happens on other version of AT&T Un*x. I realy have no idea what happens in the spring when the system goes from STD to DST. As I'm sure you know, killing cron with the -15 option and then restarting it will get cron back to a sane state. I thought about calling the support line on this little problem, but since it only happens once a year - why take the chance on installing some update they may send. -- John Mullins frederick, Md.
guy@auspex.UUCP (Guy Harris) (11/06/88)
>Our 3B2's running sysVr3.1 ran all the crontab entries twice after >the change from DST. I kind of expected that for the entries between >1 and 2 AM, but the subsequent entries also ran twice. Is this >normal? No. It's caused by "cron" not understanding how to deal with converting local time <-> UNIX time and, in particular, how to deal with DST. I don't remember the details; it's fixed in SunOS 4.0 (which has a "cron" based on the S5R3.1 one) by having "cron" use "timelocal" to do the conversions rather than trying to do them itself. Unfortunately, S5R3.1 doesn't have "timelocal" (converts a "struct tm" into a "time_t"); it's from the Arthur Olson time zone code, which SunOS 4.0 uses. S5R4 will have "mktime", assuming it supports ANSI C, which pretty much does the same thing.