Path: utzoo!attcan!uunet!sco!rosso From: rosso@sco.COM (Ross Oliver) Newsgroups: comp.unix.xenix Subject: Re: Cron mysteriously stops cronning. Message-ID: <3242@viscous.sco.COM> Date: 22 May 89 06:34:35 GMT References: <660@marob.MASA.COM> Reply-To: uunet!sco!rosso (Ross Oliver) Organization: SCO Technical Support Lines: 32 In article <660@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes about cron ceasing to function, even though the process remains. There are two distinct cron problems in the various versions of SCO XENIX currently in the field. The first is that cron runs jobs when it shouldn't, and the second is that cron seems to go to sleep forever. The first problem exists in all versions (86, 286, and 386) prior to release 2.3.1: if more than about 19 hours (64K seconds) is supposed to elapse between cron jobs, cron will execute the job at the proper time, and again about five hours later. This is caused by the fact that the number of seconds cron is supposed to sleep exceeds the maximum size of the short int that is passed to alarm(S), so the elapsed time gets truncated. This most often happens when there is only one cron job that executes once per day. You can work around this bug by giving cron something to do (like execute /bin/true) at least every 12 hours. This problem is fixed in release 2.3.1 and later, and a new version of cron is available from Tech Support for 286 and 386 2.2.3. The second problem exists only in 386 versions, and is actually a bug in the operating system itself. As I understand it, the parameter passed to alarm(S) by a 286 process (which cron is) is incorrectly sign-extended when converted to a 386 int. Thus, the alarm signal is scheduled to be sent in 20 years rather than tomorrow morning, and cron goes to sleep for a very long time. This is fixed in release 2.3.2. Like the first problem, you can also fix it by giving cron some extra things to do so it never has to sleep for more than 12 hours. Ross Oliver Technical Support The Santa Cruz Operation, Inc.