The daemon() and killproc() functions defined in the
the file "functions" from initscripts is causing hangs
at bootup on Alpha/Jensen. I am looking into this. As
a horrible workaround, I've just returned immediately from
these function and started/stopped system services by
hand. Yuck! I'll try to narrow down the problem. I don't
know why this just happens on Jensen since my other Alpha
boxes work fine with these functions. Might have something
to do with the generic kernel for RH6.0 not working on
Jensen. I'll have more details soon to help you resolve
this since I know you don't have a Jensen box.
Does the Jensen have some sort of weird console?
Out of curiousity, if you try the latest initscripts from Raw Hide
(unfortunately, this might pull in some other requires), does
that fare better?
One thing that should narrow the hang down fairly quickly is to
add 'set -x' to the beginning of daemon() & killproc().
I've narrowed the problem down. There is nothing wrong with daemon()
or killproc() per se. It's the call to pidofproc() in each that is
causing the hang. In particular, the call to awk is hanging. Sure
enough, I tried running awk alone from the command line. It hangs
every time on Jensen. :-( Looks like it's broke...maybe a compiler
bug in EV4 machines? Hmmm. Anyway, several options here...you could
use grep/cut/sed/perl instead of awk to parse the field in ps output.
Better yet, why not just dump the calls to awk? You are already
checking for the process id with pidof. There is really no reason
to be redundant. I'm sure pidof takes care of checking the process
table better than searching the output of "ps ax".
A workaround for Jensen owners is to return "0" just before the
awk invokation. More seriously, awk is broken on Jensen. Maybe
building without optimizations could fix it.
Out of curiosity, if you do 'strace awk', what exactly
*is* it doing?
Does the awk currently in Raw Hide (gawk-3.0.4-1)
work any better? If awk is broken, more things are
going to break, probably in bizarre ways.
*** This bug has been marked as a duplicate of 5946 ***