larry@focsys.uucp (Larry Williamson) (05/29/90)
Cron seems to be executing some jobs multiple times. Not always, and when a duplicate execution is taking place, they are always within 1 second of each other. Interesting thing too, is that the first execution often appears to be 1 second early! There is only one cron task running. The 'periodic' jobs seems to be the most frequent offender, but others too. Here is an example of my /usr/lib/cron/log file. > CMD: /usr/lib/uucp/uudemon.poll ---\ > uucp 233 c Mon May 28 15:09:59 1990 | Note these are 1 second < uucp 233 c Mon May 28 15:09:59 1990 | apart. > CMD: /usr/lib/uucp/uudemon.poll | > uucp 240 c Mon May 28 15:10:00 1990 | < uucp 240 c Mon May 28 15:10:00 1990 ---/ > CMD: /usr/lib/sa/sa1 ---\ > sys 260 c Mon May 28 15:59:59 1990 | > CMD: /usr/lib/sa/sa1 | These are *very* close > sys 263 c Mon May 28 16:00:00 1990 | < sys 260 c Mon May 28 16:00:00 1990 | < sys 263 c Mon May 28 16:00:01 1990 ---/ > CMD: /bin/sh /usr/adm/periodic/driver hourly >/dev/null 2>&1 > periodic 267 c Mon May 28 16:04:59 1990 < periodic 267 c Mon May 28 16:05:00 1990 > CMD: /bin/sh /usr/adm/periodic/driver hourly >/dev/null 2>&1 > periodic 276 c Mon May 28 16:05:00 1990 < periodic 276 c Mon May 28 16:05:00 1990 Could the problem be timed? I have this problem on all the Mips machines on the network (M/120's RISCos 4.01 and RC2030's RISCos 4.10). Only one machine is timed's master. Any other ideas? I've carefully gone over the cron files, the crontabs directory, and the jobs executed. Everything looks okay. This does not happen on our Sony News stations or any of our 386/ix machines. -Larry
jay@mips.COM (Jay McCauley) (05/29/90)
In article <LARRY.90May28215600@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: > >Cron seems to be executing some jobs multiple times. Not always, and >when a duplicate execution is taking place, they are always within 1 >second of each other. Interesting thing too, is that the first >execution often appears to be 1 second early! > ... stuff deleted ... This was (note the past tense) Problem Report 5077 (and other duplicates). It has been fixed for RISC/os 4.50. The problem was a race condition in cron. -- Jay McCauley MIPS Computer Systems, 928 E. Arques, Sunnyvale, CA 94086 (408)991-7711 {decwrl,pyramid,ames}!mips!jay jay@mips.com
nancy@mips.COM (Nancy Louie) (06/04/90)
>... stuff deleted ... >This was (note the past tense) Problem Report 5077 (and other duplicates). >It has been fixed for RISC/os 4.50. The problem was a race condition in cron. > Additionally, depending on your support contract, you may be able to call the support line and ask the dispatcher to log a call for you. There is a patched clock script that you can binary reconfig into your kernel that might help you. (Note the use of might. It didn't fix all cases, but the 4.50 os does.) Another thing that you can do is to try to avoid having processes start at or about midnight when the system clock is changed over to the new date. These will help until 4.50 releases.