Subject: Re: Unkillable processes
To: None <tech-kern@NetBSD.ORG>
From: Jon Ribbens <email@example.com>
Date: 11/15/1996 11:51:05
Guenther Grau wrote:
> I think I know quite a bit about Unix-internals, but I was never
> really able to figure out why it is _neccessary_ to have a process
> in a state in which it cannot be delivered a SIGKILL. Can anybody
> clue me in on that one?
> I know that this usually happens when a process is waiting for
> 'fast' i/o, but why is it really needed, or this this just an
> optimization. IMHO, it should always be possible to remove
> a process from a system, regardless what the process is just
As I understand it you can't kill a process if it's currently
executing a syscall. Maybe the syscall is in the middle of
updating something important, and if you killed it it might
leave kernel data structures corrupt. To be able to kill
a process at any point you'd need to make every syscall
be able to tidy-up from itself at any point during its
The above may be entirely wrong - I know nothing and
I'm guessing ;-).
I managed to get NetBSD 1.1 to deadlock the other day. I was
copying a file to disk, and tried to 'ls' the disk at the
same time (stupid me). Both processes got stuck in the 'D'
state and I had to reboot. Ho hum.
Oh yes, while I'm here - if I 'ping -f', my (EIDE) hard drive
locks up. (something about lost interrupts) Anybody know
why? (Intel Atlantis motherboard)
\ // Jon Ribbens // 10MB virtual-hosted // www.oaktree.co.uk
\// firstname.lastname@example.org // web space for 49UKP //