From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19-7.0.1 i686; en-US; 0.8.1)
Gecko/20010326

a comment from drdisk in bug 19129..

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


fellow's quite right, so I'm filing this separate bug for him

funny thing about that run-parts thing

(sleep 5&) && echo foo
echos foo immediately
(sleep 5&) | cat - && echo foo
waits 5 seconds before echoing foo. run-parts puts it's subserviants
through an awk pipe, so that's apparently why we're seeing that waiting around.

no terribly quick fix for this I think, and anyway this is being done the
wrong way in the first place. I'm pretty sure crond should be able execute
it's charges in serial and not have people trying to fork off into the
background on it. sysstat's /etc/cron.* scripts are the only ones that try
to do this. What shouldn't be done is having an hourly crond script that
runs for an hour, instead it should be a /etc/cron.d script that runs once
every 10 mins like this:

*/10 * * * * root /usr/lib/sa/sa1 1 1

run every 10 mins with an (arbitrary) 1 second interval and a (more
important) iteration count of 1