> On Sun, 2 Feb 1997 aidas@ixsrs4.ix.netcom.com wrote:
> >
> > Unfortunately, it then locked _that_ console hard. Signal 9's did nothing
> > for this.
> >
>
> mke2fs was already in disk sleep stat, i.e. uninterruptible. Anything
> trying to access your hda1 will wait for mke2fs to complete, and because
> of the hung caused by the buggy encryption thing, it will never complete.
That's what I figured. I would have thought a signal 9 would have nuked
it, though.
What I found out right after I sent the message (which I was in a hurry to
do since the system was apparently unstable as hell) that the processes
that were terminating were split into two groups. Some of them, such as my
number cruncher, just wouldn't die for some reason. The others released
their memory and resources, but stayed in the process table.
I figure that's normal when something gets hung in such a loop, though.
wait() might not have been called.
> And trying to halt will result in a whole mess: unmounting filesystem
> will hang, syncing fs will hang...
There we go! :)
> wait for the system to be quiet, do ctrl-alt-del (reboot or halt), look
> at the mess to happend, then press reset... Aargh, thats the only thing
> to do. Sorry, the kernel is not preemptible.
That's basically what I did.
I posted this as a possible bug in the kernel process handling or disk
code (which apparently isn't the case), and a bug report for the loopback
encryption.
I figure what happened is that the kernel got confused with the
loopback-loopback arrangement I had set up and hosed itself when it went
to actually write to the second loop device. The answer, of course, is
"Just don't do that."
-- "Things fall apart; the centre cannot hold. Mere anarchy is loosed upon the world; The blood-dimmed tide is loosed, and everywhere the ceremony of innocence is drowned; The best lack all conviction, while the worst are full of passionate intensity." -- "Second Coming" by Yeats.