From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.16 i586)


After booting, occasionally run-parts (launched from anacron) never
finishes.  I wish I could be completely sure that it was run-parts that was
causing the problem, but I'm not.

Here's the details:  anacron and cron are started from the rc scripts with
nice value of 19 (my change, hoping to reduce the problems I'm about to
describe, without any luck).  Once updatedb starts running (seems to be
running simultaneously), I hear the disk drives start.  Approximately 6GB
of IDE diskspace is scanned quickly, and then the 36GB SCSI drive starts
going.  It keeps going and going.  Getting a shell and running top is
difficult.  Strangely, the load figures are around 7 and 8, but top reports
74% idle.  top and awk are listed as the only things running (R), while
updatedb is listed as being in an uninterruptible sleep (D N, to be
specific) for what it's worth.  I managed to kill the awk process after 40
minutes (try killing in X, can't get prompt, switch to virt. term. 2, etc,
all very slow).

The awk line in question, from run-parts, looks like

       if [ -x $i ]; then
                $i 2>&1 | awk -v "progname=$i" \
                              'progname {
                                   print progname ":\n"
                                   progname="";
                               }
                               { print; }'
        fi

Anacron mails me to tell me that run-parts of cron.daily died when awk was
killed.  Also, for what it's worth, my scsi controller is a Tekram
DC390U2W, and I'm using the sym53c8xx driver from the
"kernel-2.4.1-0.1.14.i386.rpm" package.  The drive is an 36GB IBM Ultrastar
36LZX (DDYS-T36950).

Reproducible: Sometimes
Steps to Reproduce:
1.reboot, and see what happens
	

Actual Results:  Sometimes the problem occurs, sometimes it doesn't.  This
is why I mentioned that updatedb was trying to run simultaneously, but
spent most of it's time in an uninterruptible sleep (the awk process
evidently has really grabbed the disk and won't let go).  I'm guessing
there's some kind of interplay going on.

Expected Results:  Anacron, for cron.daily, should have quickly finished
it's work (i.e. in 5 minutes or 10, instead of not finishing after 40).