Bug 19129

Why not make it "0 * * * *" and drop the "0-6" altogether?

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 :)

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>
 #
 S_TIME_FORMAT=ISO ; export S_TIME_FORMAT
-DATE=`date +%d`
+DATE=`date -d yesterday +%d`
 RPT=/var/log/sa/sar${DATE}
 ENDIR=/usr/bin
 DFILE=/var/log/sa/sa${DATE}


Have a look at /usr/lib/sa/crontab.sa and you see what happened ...

*** Bug 19286 has been marked as a duplicate of this bug. ***

*** Bug 20513 has been marked as a duplicate of this bug. ***

*** Bug 20513 has been marked as a duplicate of this bug. ***

*** Bug 20644 has been marked as a duplicate of this bug. ***

the rpm that will soon be available in rawhide (3.3.3) fixes these problems. 
Please test.

*** Bug 23237 has been marked as a duplicate of this bug. ***

regarding weo'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 ;)

[hoshem.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 ...

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)

an updated errata release is coming shortly which finally fixes the lingering
crontab issues.

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
  seconds)

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.