Level 1

23 points

kill command doesn't do anything - Is Mac OS X REALLY Unix

A few times now I have had trouble getting various apps to quit. I try using Force Quit, but that almost never works.

Aside on Force Quit: With apps that are not responding, I choose Force Quit from the Apple menu, then as I select apps and click the Force Quit button, they obediently disappear from the list, but nothing seems to actually be happening - the app is still there, and when I close and reopen the Force Quit dialog, they're back in the list! Force Quit from the context menu of their dock icons also does nothing...

Anyway, so having tried Force Quit and not gotten anywhere, I open up a Terminal window (thinking, here we go, OS X is Unix so I can get right down to the low-level stuff here). I use ps to find out the PID of the app's process and use kill -9 <PID> to try to terminate it manually.

...but NOTHING! If I run the ps command again, the process is STILL THERE!

So now I'm thinking, hang on a second! This is supposed to be Unix, uber-low-level control! I've never had the kill command not work on any other Unix system...

Maybe I'm a paranoid conspiracy theorist or something, but this experience has made me wonder if OS X really is Unix and not some kind of Unix emulation wrapped around a proprietary kernel.

Someone please put my fears to rest (and oh yeah by the way also help me with the kill command thing).

Posted on Oct 16, 2005 9:49 PM

38 replies

Oct 17, 2005 8:22 PM in response to Nils C. Anderson

Hi Andy,
That's a nice explanation; I've saved it. There's one point on which I'm a little fuzzy. Can you elaborate on "goes into the kernel"? Thanks.
--
Gary
~~~~
"Whoever undertakes to set himself up as a judge of Truth
and Knowledge is shipwrecked by the laughter of the gods."
-- Albert Einstein

Oct 17, 2005 10:06 PM in response to Gary Kerbaugh

UNIX protects sensitive system data structures (which could affect multiple users) by restricting access to code that executes within a separate "kernel" address space*. When a process does something which needs to modify those structures, it does so by using a special machine instruction (a "trap") which causes execution of operating system code in the kernel address space. Examples of such operations are I/O (changes the system file table, the file system cache, and of course the data on devices), process scheduling (changes the scheduling queue), and inter-process communication... Most low-level C library routines (open/close/read/write/poll/sleep/map etc.) are wrappers around kernel traps.

"Going into the kernel" is executing a trap.

* Processes can't read or write each other's address spaces except through
instructions that can only be executed by the kernel.

Oct 18, 2005 5:15 AM in response to Karl Zimmerman

Hi Karl,
Now that can't be beat! I can tell that you know the depth to which I like to understand things.
--
Gary
~~~~
I used to work in a fire hydrant factory. You couldn't park
anywhere near the place.
-- Steven Wright

bdinmstig Author

Level 1

23 points

Oct 18, 2005 5:18 AM in response to Gary Kerbaugh

OK, what you're saying makes sense, but I don't think it was a process owned by another user. I mean, I'm the only user on my machine, and from memory, I started the process myself... I'll have to pay better attention next time to see who the owner is, but anyway, when I do a kill or killall and I'm no the owner, I usually get an error message saying "you are not the owner" or something to that effect.

Next time it happens I'll pay more attention to the owner and report back.

Oct 18, 2005 5:26 AM in response to Karl Zimmerman

Looks like Karl answered the question for you Gary. And much clearer that I could.

Andy

bdinmstig Author

Level 1

23 points

Oct 18, 2005 5:27 AM in response to Gary Kerbaugh

But if you're doing a Force Quit, it's precisely because the process has hung and there is no opportunity for it to clean up after itself. Maybe the OS X designers had something else in mind, but as a user, my interpretation of "Force Quit" is "I know there is a potential to lose or corrupt data, but I think we're past that point now and I just want this thing to die". In fact, when you use the GUI to Force Quit it tells you that you might lose data.

The point is, from the GUI, Force Quit is your last option, therefore it should do whatever is necessary at the OS level to stop that process. The fact that there is a way to do it from the CLI doesn't enter into it. GUI builders should assume there is no CLI. That's because avoiding the use of a CLI is the justification for having GUIs in the first place.

Bill Scott

Level 6

11,465 points

Oct 18, 2005 10:23 PM in response to Gary Kerbaugh

It is getting harder and harder to trump reality

reese_

Level 4

1,735 points

Oct 18, 2005 10:40 PM in response to bdinmstig

I'm the only user on my machine

Not as far as the system is concerned. There are lots f users on any *nix system (that's part of the definition of Unix or Unix like system, including Linux).
For example, if you print someting then you have passed asked the user 'lp' to do a something. You may have been the one who started things but lp initiated the process. Open your NetInfo manager and check out all the users-- but don't delete them (as a client once did). Some consultants charge double to fix that sort of thing.

Reese

Robin F

Level 2

400 points

Oct 18, 2005 11:25 PM in response to Deano

Whew, you guys are good...i think...I mean if I understood it...

Anyway, I just option-command-escape when I have trouble force quitting, and pick those rascals off one by one

Thanks for the UNIX info

Finlay

Level 4

2,415 points

Oct 19, 2005 1:28 AM in response to Karl Zimmerman

For GUI processes, I believe "Quit" (not force quit) will send the quit AppleEvent first, which gives the process a chance to exit gracefully.

Dogcow-Moof

Level 8

36,839 points

Oct 19, 2005 3:35 AM in response to Karl Zimmerman

This of course ignores the entire issue of shared memory which explicitly allows processes to read and write data in areas without any help from the kernel other than setting up the shared mappings in the first place

Dogcow-Moof

Level 8

36,839 points

Oct 19, 2005 3:42 AM in response to Karl Zimmerman

This ignores the most common reason for the spinning wheel and the inability to kill a process, namely it's asleep in the kernel waiting on a resource.

The most common example of this in UNIX is a process in "disk wait" state. This means the process has requested data from the disk and is asleep waiting for it.

A process in disk wait is asleep in the kernel and is not killable, because of the way signals work:

When you kill a process, you're sending it an asynchronous signal. But what really happens is the kernel sets some bits in that process' memory structures telling it that it should deliver the signal to itself the next time it runs.

But guess what - if the process never awakens because it never gets the disk block it's waiting for, it will never execute, thus it will never deliver the signal to itself. Voila! An "unkillable" process.

But since this process still exists, it will still show up in the output of ps and Activity Monitor. You can continue to attempt to kill it all you like, but all that's happening is the kernel is setting the same bits in the data structure telling the process it has to deliver a signal to itself the next time it runs.

The key to all this is that most things a process sleeps waiting for do not fall into this category, and the kill will cause the process to be marked runnable which will cause the process to awaken and deliver the signal to itself as expected.

reese_

Level 4

1,735 points

Oct 19, 2005 6:44 AM in response to bdinmstig

I'm the only user on my machine

danuke

Level 3

892 points

Oct 19, 2005 6:51 AM in response to Dogcow-Moof

holy cow! that sounds scary as all get out. is this the zombie state I read bout earlier, and is the force quit the way to kill this thing, other than pouring salt into the box?

trav

Oct 19, 2005 6:59 AM in response to Dogcow-Moof

OK, good point -- although I did list "map" as one of the low-level C library routines implemented as a wrapper around a trap.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

kill command doesn't do anything - Is Mac OS X *REALLY* Unix