Bug 142656 - CORE fails due to misplaced 'return 0'
CORE fails due to misplaced 'return 0'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Ready Certification Tests
Classification: Retired
Component: backend (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rob Landry
:
Depends On:
Blocks: 142571
  Show dependency treegraph
 
Reported: 2004-12-11 16:13 EST by Jay Turner
Modified: 2015-01-07 19:09 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-03 09:55:06 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 Jay Turner 2004-12-11 16:13:22 EST
Description of problem:
You've probably already found this, but with rhr2-rhel4-0.9-14.9i, there's a
'return 0' in CORE as the very first line of the pi() subroutine.  This is the
reason that CORE is failing with that line about "pidof bc" . . . those
processes are never getting started.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Rob Landry 2004-12-13 01:00:46 EST
Yup; that was thrown in during testing; guess it got missed.  A little more work
could go into it if we wanted; since in theory it would be ok if the bc's didn't
make it to the end in which case we'd need to wrap that up in an if to keep
execfail from failing the test...

if pidof bc; then
 while pidof bc; do
   if killall -9 bc; then true; done
 done
fi
Comment 2 Rob Landry 2004-12-13 01:09:10 EST
Course this could also be an infinent loop; should we fail to killall bc; which
I'm not certain we really care about one way or the other; so probably go with...

if pidof bc; then
 if killall -9 bc;l then true; done
fi

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