Re: Resource locks and unkillable processes in 2.1.24

Philippe Strauss (
Mon, 3 Feb 1997 13:18:02 +0100 (MET)

On Sun, 2 Feb 1997 wrote:

> I installed the 2.1.22 encrypted filesystem patches, then patched up to
> 2.1.24. Everything patched fine, and everything works fine, except for one
> thing.
> I was playing around and decided to make /dev/hda1 an encrypted filesystem
> via loopback. I did a 'losetup -e idea /dev/loop0 /dev/hda1'. Then I made
> an ext2fs filesystem over /dev/loop0, which of course wound up on
> /dev/hda1. Then I mounted the thing.
> I set up some directories, and, playing around, decided to make another
> encrypted filesystem on top of that. So I go into a directory under the
> encrypted filesystem and make a 40MB file by loading in data from
> /dev/urandom. Then I mounted this file under /dev/loop1 using IDEA
> encryption.
> When I went to make a filesystem on the 40MB file (/dev/loop1), it seemed
> to go rather fast. Then mke2fs hung at "Writing superblocks and filesystem
> accounting information." I sent it SIGINTs via CTRL-C to no avail. I sent
> it a SIGTERM, but it did no good. I sent it a few signal 9's, but nothing
> happened.
> Seeing what would happen, I went onto another console and tried to
> 'losetup -d /dev/loop1'. I got this, of course:
> root:~# losetup -d /dev/loop1
> ioctl: LOOP_CLR_FD: Device or resource busy
> 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.

> Looking at my load factor:
> 10:34pm up 1 day, 5:46, 7 users, load average: 4.99, 4.38, 3.14
> It seems to be getting higher. The load factor _should_ be at 1.00 all the
> time, though, because I'm running a number crunching task in the
> background.

you may use top to see which process are in R mode (running). sometimes,
in bad situation like yours, some process still in running state, even if
they don't use much the cpu, and get counted in load avg.

> 'ps' reveals that both losetup and mke2fs are stuck in state 'D', which is
> "uninterruptable sleep." Both the processes have also been swapped out (in
> state 'W'), so it doesn't appear that they're actually doing anything.
> Since it's been hung for quite a while, it's beginning to look like the
> only way to fix this is to shutdown and reboot.

Absolutely. Thats the price to pay in experimenting :)

> In preparation for reboot right now, I sent mprime, my number cruncher, a
> SIGINT, which it is supposed to capture and exit on after dumping some
> data. Instead, it promptly turned into a zombie process. I can't kill it
> either. Signal 9's are ineffective.
> Now 'sync' just locked up _another_ virtual terminal. And *any* process I
> try to kill turns into a zombie.

And trying to halt will result in a whole mess: unmounting filesystem will
hang, syncing fs will hang...

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.

> Something is -really- hosed.

I had similar thing by shutting the power on a mounted zip drive...

> --
> "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.

Philippe Strauss, ingenieur en telecommunications.

Email: <>

"Death can come quickly to a market leader."
-- Bill Gates, "The Road Ahead"