Bug 19129 - crontab still wrong for sysstat
crontab still wrong for sysstat
Product: Red Hat Linux
Classification: Retired
Component: sysstat (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
David Lawrence
: 19286 20513 20644 23237 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-10-15 03:47 EDT by Rudi Heitbaum
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-08 06:19:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rudi Heitbaum 2000-10-15 03:47:58 EDT
0 * * * 0,6 root /usr/lib/sa/sa1 600 6 &

should be 

0 * * * 0-6 root /usr/lib/sa/sa1 600 6 &

Else it will only run on sunday and saturday.
Comment 1 Frank Ch. Eigler 2000-10-23 19:30:44 EDT
Why not make it "0 * * * *" and drop the "0-6" altogether?
Comment 2 h0e 2000-12-25 04:58:02 EST
bugs 19286, 20513 and 20644 are duplicates of this
20925 is related
several of sysstat's resolved bugs have additional comments after the fact about
this bug
all of it adds up to sysstat's crontab entries are still incorrect
sa1 runs on sunday & saturday only, whereas sa2 runs every day, causing it to
complain about missing sa1 reports on mon-fri. It looks like the intention was
for sa1 to run every day, so changing 0,6 to * seems the right solution

several people (eg. bug 20925) have suggested that the rpm should stop mangling
/etc/crontab and make a /etc/cron.d/sysstat instead. I agree :)
Comment 3 Wolfgang Ocker 2001-01-02 14:38:35 EST
The crontab entry for sa2 should read:

5 0 * * * root /usr/lib/sa/sa2 -A & 

and /usr/lib/sa/sa2 should be changed as follows:

--- sa2.orig	Tue Jan  2 20:37:56 2001
+++ sa2	Tue Jan  2 20:41:04 2001
@@ -3,7 +3,7 @@
 # (C) 1999,2000 Sebastien Godard <sebastien.godard@wanadoo.fr>
-DATE=`date +%d`
+DATE=`date -d yesterday +%d`

Have a look at /usr/lib/sa/crontab.sa and you see what happened ...
Comment 4 Preston Brown 2001-01-05 15:40:16 EST
*** Bug 19286 has been marked as a duplicate of this bug. ***
Comment 5 Preston Brown 2001-01-05 15:40:44 EST
*** Bug 20513 has been marked as a duplicate of this bug. ***
Comment 6 Preston Brown 2001-01-05 15:41:07 EST
*** Bug 20513 has been marked as a duplicate of this bug. ***
Comment 7 Preston Brown 2001-01-05 15:41:32 EST
*** Bug 20644 has been marked as a duplicate of this bug. ***
Comment 8 Preston Brown 2001-01-05 16:45:35 EST
the rpm that will soon be available in rawhide (3.3.3) fixes these problems. 
Please test.
Comment 9 Preston Brown 2001-01-05 16:48:14 EST
*** Bug 23237 has been marked as a duplicate of this bug. ***
Comment 10 h0e 2001-01-06 10:01:30 EST
regarding weo@recce.de's comments, if I'm not mistaken he intends to generate
the sar file for some day the following day, to make sure all data has been
collected for the aforementioned day :)

hmm I wouldn't change the sa2 executable like that, hard coding in different
behaviour. you could do just leave the sa2 file as it is and change sa2's
crontab entry to run at 23:55 (55 23 * * * root etc.)

on the other hand, it shouldn't do any actual harm to generate an sar file
before the matching sa file has gathered all it's data, you can always
regenerate one manually later if it turns out you need the "after hours"
information, and it might be more useful for administrators to have their sar
files generated at an earlier time, like 7pm as it is done at the moment, I
don't know though

ahh well, for the sake of my conscience, make this modification (if you will) by
changing the crontab entry to execute at 23:55 and leave the sa2 file as it is ;)
Comment 11 Wolfgang Ocker 2001-01-07 19:47:58 EST
[hoshem@mel.comcen.com.au]: Okay, but then we should do it the "right" way and
make the day we want to create the report for an argument for the sa2 script?

Maybe it becomes overengineered ...
Comment 12 h0e 2001-01-08 06:19:19 EST
well you could do that, but you don't need to, because the last sa1 run of the
day is at 11:50pm, not at midnight, so you can run sa2 at 11:55 (23:55)
Comment 13 Preston Brown 2001-01-17 11:50:15 EST
an updated errata release is coming shortly which finally fixes the lingering
crontab issues.
Comment 14 Christian Hechelmann 2001-04-25 13:03:03 EDT
sysstat-3.3.3-3 still has wrong crontab entries:

- /etc/cron.hourly/sysstat runs sa1 with the parameters 600 6, this tells
  sa1 to run at x, x+600, ... x+3000 and x+3600 seconds. Thus on the hour
  sa1 is run *twice* within a few seconds.

- /usr/bin/run-parts from crontabs-1.8-1 (which actually runs the stuff in
  /etc/cron.* hangs while executing sysstat's hourly entry until sa1 exits,
  despite sa1 beeing started with &,  which it does after an hour, just when
  the next run should occur, thus effectively delaying all cron.hourly entries
  that are lexically greater than sysstat by one hour. Might be the cause for
  problems I'm experiencing (crontab entries are run multiple times within

Comment 15 h0e 2001-04-26 03:25:20 EDT
bzzt :)

actually, x+3600 is not run

x <-- 1
x+600 <-- 2
x+1200 <-- 3
x+1800 <-- 4
x+2400 <-- 5
x+3000 <-- 6

and that's already 6 iterations. One of those funny off by one things
Your thing about run-parts stalling is a concern though, and I filed a separate
bug 37733 for you.

Note You need to log in before you can comment on or make changes to this bug.