SUMMARY:Strange Crontab timing issues

From: Gary Beckett <gbeckett_at_myra.com>
Date: Thu, 02 Aug 2001 13:08:57 -0700

Well, I received many responses to this issue and thanks to all that
responded. Very much appreciated. This is a great mailing list.
Most of the response I got I had already tried with no success and a
couple I hadn't thought of so tried but with no success. I will
summarize for the list incase it helps someone else in the future.

A few people mentioned that it could be to do with the NTP
synchronization.
    - Checked and re-checked this then re-setup NTP from scratch again.
Ran "ntp -v <timeserver>" Checked out perfectly.

A few people mentioned changing the "max_jobs" variable in the file
/var/adm/cron/queuedefs from the default 25 to something like 50 and
re-HUPing crond.
    - Did this a couple weeks ago. No luck in resolving this issue

A couple of others mentioned looking a the /etc/zoneinfo/localtime file
to make sure that it is setup for our correct location.
    - Hadn't thought of this one so looked into it. Found that one of
the servers /etc/zoneinfo/localtime was not a symlink to
./Canada/Pacific. Created a symlink to it and will monitor.

A couple others mentioned running the "timezone" utility to re-setup the
timezone.
    - Did this, but no success.

Thanks again to everyone.

---------------------------------------------------------------------------------------------------

Original question:

Hi there.
I have searched the archives for this type of problem and only found one

instance of the exact same problem but no summary. ARG.......
I have a couple of TRU64 4.0f boxes with patch kit 4 installed. One is a

DS20 and the other is a 1000/A. Both seem to be experiencing that same
problem with timing the crontab events.
This has being going on since before joined this site so can't specify
when this might have started or what might have happened to start this
problem.
I noticed some strange behavior with cron, so I wrote some simple
scripts to capture the date & time and do a "ls -l" of a curtain
directory and email them to me. The root crontab's have been setup the
same on both systems.

Root's crontab on both 1000/A & DS20
0,15,30,45 * * 7 * /var/local/perfdata/script1
00 22 * 7 * /var/local/perfdata/script2
05 1 * 7 * /var/local/perfdata/script3

On both the 1000/A & DS20 "script1" runs exactly on schedule and the
email response is exactly what I expect

On the 1000/A "script2" doesn't start until 22:15

On the DS20 "script2" doesn't start until 23:15

On both the 1000/A & DS20 "script3" runs exactly on schedule and the
email response is exactly what I expect

These systems have a system reporting utility installed on them that is
very time sensitive. If a file is not written to by a curtain time the
the whole reporting structure falls over. I've pin pointed cron as the
problem as it is not running the schedule stated in it's crontab file.
With the results from these test scripts and looking at the reports time

stamp it seems that cron on the DS20 is exactly 1 hour fast. Yes, I have

checked the date on both systems and it reports exactly what it should
be.
I'll leave it at that. If anyone has experienced this type of problem or

if I could add any more info to help resolve this, please let me know.
Thanks in advance,

--
Gary Beckett
Myra Systems Corp.
gbeckett_at_myra.com
Received on Thu Aug 02 2001 - 20:09:46 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT