NEAL_HOLTZ@CARLETON.BITNET (NEAL HOLTZ) (03/03/86)
This doesn't seem to be very important, but I am curious. On one of our file servers, the mbx_helper process shows up in the 'pst' listing as unnamed (i.e., with a UID number). It is started the regular way from startup.spm via a 'cps /sys/mbx/mbx_helper', exactly as it is on other servers. Only on one is it unnamed (of course, it doesn't show up in `node_data/proc_dir on that node, but does on others). It doesn't seem to affect anything. Any clues? I guess I could try copying /sys/mbx/mbx_helper from another node, but I would like to understand what's going on. Neal Holtz
mishkin@APOLLO.UUCP (Nathaniel Mishkin) (03/03/86)
This doesn't seem to be very important, but I am curious. On one
of our file servers, the mbx_helper process shows up in the 'pst'
listing as unnamed (i.e., with a UID number). It is started the
regular way from startup.spm via a 'cps /sys/mbx/mbx_helper', exactly
as it is on other servers. Only on one is it unnamed (of course,
it doesn't show up in `node_data/proc_dir on that node, but does
on others).
Sometimes, names get "stuck" -- the name of a previously incarnated process
stays around (in "`node_data/proc_dir") even after the process goes away.
(Typically, the process has to die in a somewhat horrible way for this
problem to arise.) This sometimes prevents NEW processes from using the
same name. One or both of the following should fix your problem: (1)
"dlf `node_data/proc_dir/mbx_helper"; (2) reboot your node.
-- Nat Mishkin
Apollo Computer
apollo!mishkin
-------holtz%cascade.carleton.cdn%ubc.CSNET@CSNET-RELAY.ARPA (Neal Holtz) (03/04/86)
Actually, I suspect I have the answer to why mbx_helper was unnamed,
and it wasn't very important. 'startup.spm' had the line
'cps /sys/mbx/mbx_helper' in it, but when I was watching the diagnostics
on a CRT attached to the DSP-80 during boot, I noticed the message at the
end of the boot process that said:
"MBX_HELPER not running. Starting one"
I bet that 2 copies of mbx_helper got started, the first one died
after having named itself, and the second (unnamed one) continued.
I removed the "cps ..." command from the startup file; at the next crash
(shouldn't be long) we will see if that was the problem.
Is this right? Seems a little strange.holtz%cascade.carleton.cdn%ubc.CSNET@CSNET-RELAY.ARPA (Neal Holtz) (03/06/86)
It has been confirmed. The reason that the mbx_helper process was unnamed in our DSP's was that the SPM was starting one at the end of the boot process, even though the startup file also started one. I moved the 'cps /sys/mbx/mbx_helper' line to the front of the startup.spm file, now everything seems to be fine.