Conference azur::mcc

3130.0. "Ultrix - failure to enroll AM in R state" by MICROW::LANG () Thu Jun 04 1992 10:30

	We're running on Ultrix, using MCC 1.2.7, and recently ran into
	this strange situation.  The Access Module we wrote was not
	up, and an enroll was issued to bring it up. The successful
	enrollment message was not returned, but the process (called
	mcc_tps_am) did start.  When we looked at the process, it
	was in the run state, and was consuming CPU.  We don't do
	anything unusual in the probe routine. 

	After this occurred, I issued another enroll, which killed this
	process, and brought another one up successfully.

	Does anyone know what would cause this situation?  We've been
	running successfully for a while, and this is the first time
	we've seen it, so it doesn't seem to happen frequently.

			thanks,

				Bonnie

DECmcc (T1.2.7)

Waiting: MM mcc_tps_am has not completed startup
Waiting: MM mcc_tps_am has not completed startup
Waiting: MM mcc_tps_am has not completed startup
Waiting: MM mcc_tps_am has not completed startup
Waiting: MM mcc_tps_am has not completed startup
Waiting: MM mcc_tps_am has not completed startup
Will try again on next dispatch to MM:
rock1.tay1.dec.com> ps -aux |grep mcc
priestle 13120 85.8  0.4 2088  236 ?  R      1:40 mcc_tps_am 16 Y
priestle 13123  0.0  0.1   40   32 p5 S      0:00 grep mcc
rock1.tay1.dec.com> ps -aux | grep mcc
priestle 13120 84.6  0.4 2088  236 ?  R      1:59 mcc_tps_am 16 Y
priestle 13125  0.0  0.1   40   32 p5 S      0:00 grep mcc
rock1.tay1.dec.com> ps -aux | grep mcc
priestle 13120 83.0  0.4 2088  236 ?  R      2:02 mcc_tps_am 16 Y
priestle 13127  0.0  0.1   40   32 p5 S      0:00 grep mcc
rock1.tay1.dec.com> ps -aux | grep mcc
priestle 13120 83.4  0.4 2088  236 ?  R      2:13 mcc_tps_am 16 Y
priestle 13129  0.0  0.1   40   32 p5 S      0:00 grep mcc

QAR 3113.

I have never heard of this behavior before.
Sounds like some kind of very rare race condition.

-- Erik

    I've seen something like it - the immediate cause (as the messages
    suggest) is that something is causing the MM to either hang (or take
    a VERY long time) between its main() entry point and the time it issues
    a "listen" to accept incoming connections.   Other than the MM probe
    and log routines, the only significant thing done is MCC kernel init,
    and in particular, the setup of the dispatch table and the event pool
    shared memory region.   I suspect one of the locks used to protect one
    of those resources is in some unexpected state, but unless we cah catch
    this situation in dbx, I don't know where to go from here....