[net.unix-wizards] system will not shutdown

jcc@siemens.UUCP (02/15/85)

<>

	We seem to be having a problem with /etc/shutdown.  To shut
	the system down, I usually use the command:

	/etc/shutdown -h +5 "comment"

	Shutdown starts, gives back its pid number, then just hangs there
	forever.  A "ps" of the pid shows the state "I <".  Has anyone
	else had this problem?  Is /etc/shutdown waiting for a resource it
	can not get?  As always, all suggestions or comments are welcomed.

					Thank you,

					Joe Camaratta
					princeton!siemens!jcc

chuqui@nsc.UUCP (Chuq Von Rospach) (02/17/85)

In article <93600004@siemens.UUCP> jcc@siemens.UUCP writes:
>	Shutdown starts, gives back its pid number, then just hangs there
>	forever.  A "ps" of the pid shows the state "I <".  Has anyone
>	else had this problem?  Is /etc/shutdown waiting for a resource it
>	can not get?  As always, all suggestions or comments are welcomed.

I've seen this occasionally. What seems to be happening is that the 'wall'
that shutdown does hangs on a terminal for some reason and doesn't ever
complete, and the shutdown never moves beyond that. I'm not sure why it 
should hang on the wall (^Q?) and I've never been motivated to find it--
that is what 'kill 1 1' is for...

chuq

-- 
From left field, near the warning track:          Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc!chuqui@decwrl.ARPA

Even though a poem be a thousand words, but made up of senseless words, one word
of a poem is better, which if a man hears, he becomes quiet. --The Dhammapada

preece@ccvaxa.UUCP (03/03/85)

>	We seem to be having a problem with /etc/shutdown.  To shut
>	the system down, I usually use the command:
>
>	/etc/shutdown -h +5 "comment"
>
>	Shutdown starts, gives back its pid number, then just hangs there
>	forever.
----------
This could be due to 4.2 signals.  Shutdown uses alarm signals to
break out of its attempts to write messages out to user terminals.
In 4.2 those signal routines don't do what they need to do; after
leaving the signal handler the interrupted routine is restarted,
leaving you blocked again.

The fix is to do a setjmp before the potentially blocking code and
then do a longjmp in the alarm handling routine.  I would attach diffs,
but our shutdown has been hacked for other things, too, and it would
be too much work to isolate those few lines.

scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece