Bug 30793 - crontab 1.9.1's run-parts, called from anacron (cron.daily) never finishes
crontab 1.9.1's run-parts, called from anacron (cron.daily) never finishes
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-06 05:03 EST by Need Real Name
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-09 14:49:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-03-06 05:03:05 EST
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).
Comment 1 Bill Nottingham 2001-03-06 11:33:16 EST
Hm, sounds like the VM in the kernel is behaving oddly.
Comment 2 Need Real Name 2001-03-09 14:49:43 EST
After your comment about the vm, I did some more investigating -- very slowly,
because in fact it does appear to be a vm problem.  _Every_ process (according
to ps) had RSS=0 except identd, which has RSS=4 but this hardly seems worth
mentioning.  The problem I had before was tied to running X at the same time
this wackiness started, since X doesn't do very well when completely swapped
out.

Anyway, kernel-2.4.2-0.1.19.i386.rpm seems to have taken care of this problem.

-Paul Komarek
Comment 3 Michael K. Johnson 2001-03-12 14:16:03 EST
Since you have reported it as fixed, I'll close this as "RAWHIDE" --
re-open it if you see the behaviour again.

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