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 ***