Find Stuck Process
 

Hi,

Top shows me, that there are always 2 to 5 stuck processes. How can I find out which processes these are?

Thanx
Flözen

How do you know they are "stuck"?

If top shows them "stuck" (what does stuck mean exactly anyway?) you should be able to see the PID (Process IDentification) and the name of the process. I can't check right now, but I think the PID should be the first column and the command name should be the last column. They should be labeled at the top of the table in any case. The command name will tell you which process you're interested in.

Post the output of top if you're having trouble here. Better yet, open up "Activity Monitor.app". It's located in /Applications/Utilities and should give you an easier time of identifying problem processes.

Because the System tells me, that they are stuck... :confused:

I googeld a little while for the problem before I posted here.
It is quiet interesting, that there are always only people anwering the questions to "stuck" processes in MacOS X as you did. But nobody gave an helpful answer...


I didn't want to start a philosophical disussion about the word "stuck". Apleas ask an Apple Developer how they define "stuck". ;)


Well, this is, what I am asking for... How do I find out which process (by name oder PID) is supposed to be "stuck".



But let me formulate the question a little bit different, to prevent "very smart" anwers: :D

I am using MacOS 10.5. When using the command "top" in the Terminal/shell it says, that there are "stuck" processes. After reboot they are already 2.
What does stuck mean? It "stuck" comparable to "zombie" at Linux Systems?
How do I find out which processes these stuck processes are?

Output of
is
Would be glad about useful hints.

Flözen

Does Activity Monitor.app show anything that references stuck processes?

The following thread also has info on this.
http://forums.macosxhints.com/archiv...php/t-624.html

Normally Activity Monitor shows such processes in red with "(Not Responding)" next to their names.

You'd have to ask the Unix/BSD developers. top has been around for a long time.

I don't know. But I'd be interested in finding this out.

By the way, it sounds like your stuck processes are permanently stuck. In my case, notice of a stuck process will occasionally flash in the header of the top text, but always goes away immediately.

On the other hand, it sounds like you have processes that are stuck and stay that way.

I don't believe so, no. First, top can show zombie processes, and it lists them separately from stuck processes.

Second, zombie processes are defined as having completed their execution successfully, but still have an entry in the process table. So they are dead (having completed execution) but have not gone away yet like they should have (thus those processes are "undead", or zombies).

On the other hand, I believe that a stuck process has not completed execution (remember a zombie process HAS completed execution) but is somehow delayed in some way that top can recognize.

By the way, stuck processes and zombie processes are found in both Unix (like OS X) and Linux.

Could we see your processes as well?

Trevor

No.

Yes I have found that on my search too. Unfortunatele MacOS X does not understand the u of ps -aux (although it is listed in the man pages)

the output of
is
Process 302 is one of the Terminal-Windows...

And as trevor says: zombie != stuck

This is fascinating.

Although 4 occurrences of "stuck" appear at http://www.unixtop.org/
none of them pertain to what we're discussing here.

That site indicates "top is now a SourceForge project", so
I go to http://sourceforge.net/projects/unixtop and search
the documentation and forums for "stuck". Nothing.

Well, almost nothing... I did see this ad on one page:

Sponsored links
Stuck
Discover Your Deal. Save on Stuck!
Shopzilla.com

[google is becoming one evil greedy empire, eh?] :rolleyes:

Or just look at the Darwin source code for 'top'
(http://www.opensource.apple.com/darw...e/10.5/top-37/)

Extract from the file "libtop.c":
The above seems to show that the processes that 'top' lists as "stuck" are what is otherwise known as being in an uninterruptible wait state.
The question of processes in an uninterruptible wait state has been discussed in at least one other thread on these forums some time ago - probably a year or two ago as I recall.

It's worth noting that a few processes of state TH_STATE_UNINTERRUPTIBLE isn't anything to freak about. It doesn't necessarily mean something is acting up, just in a special waiting state that isn't interruptable.

(It CAN indicate a problem, but I think if most people run top, they'll find a few processes in this state, and the number will fluctuate a little as processes go in and out of this state.)

I couldn't find anything built into either top or ps
so, here's a simple sed filter for uninterruptibles:
If desired, add more fields via ps alx or ps aux

Perhaps they could have chosen a term less negative-sounding than 'stuck'. :)

--

Hey, what the heck? That should be an uppercase U inside the brackets.
But this forum software won't let me post that. It turns it into lowercase.

Ah ha... I fooled it. :cool:

Apparently it will do 2 different things;
one with the dash (-), and one without.

I think you want ps aux
[i.e., sans dash... see the man page]

I know you're being facetious, but it's accurate. The process is, as far as can be determined, "stuck". It may become unstuck, but there's no way to know that. People using the top utility should understand this. :)

So a stuck process seem to be nothing to worry about?!

All apps of these work well... :confused:

Thanks so far :D
Flözen

It might be interesting to see how long these apps remain in the "stuck" state. Maybe try running something like:
Stop the script with Control-C and look at the output file.

How? Show me one iota of documentation.
Even googling for 'top stuck' reveals 98% questions.

idunno. How about 'busy' instead of stuck?

Please understand that the top utility is not wrong. If you feel the documentation for top needs improvement to explain the terminology it uses, feel free to file a bug report against it. There is a difference, and it's important to know, because fixing the wrong problem results in more problems.

The man page for the ps utility talks about this state, but it fails to link the word "stuck" to it, because "stuck" is language specific to the top utility. The top docs should probably have a note about it.

Because that would still be inaccurate, as "busy" suggests the process is doing something, when in reality, it may not be.

Well, it's not so much a matter of how I feel. You said 'users should understand' and
I just pointed out that there's not much out there from which we can derive same.

All I could spot in man ps was:

U Marks a process in uninterruptible wait.

Did I miss something more?

Probably? ;)

Fair enough. Thanks.

I just meant that people who use the top utility need to know what it means if using that statistic to analyse anything, that's all. Make sure you file a bug on the top documentation, re: thread/process states. (Post the radar # here, too.)

I seldom do such things.
If you haven't done it, I'm sure it's unnecessary.

[what's a radar # ?]

Well, don't complain about the documentation not explaining something to you, then. Developers can't fix problems they aren't aware of.

Actually, my "complaint" (it wasn't a complaint really) was
that: *you* said users *should* understand something...
and it turns out that something happens to be undocumented.

My (as yet unanswered) question to you was: How? :)

[if 'file a bug report' is your "answer", then... thanks so much.]

Like I said:

Please read that again, because it will alter how you read the post you keep quoting.

Therefore, the documentation should be updated, as I also said before, because users should know it. If you also find it important, you need to file a bug, too.

Using the script above, I found that SystemUIServer.app goes "unstuck" whenever I fidget around with the icons on the right of the menu bar (top of the screen). So, even though it is "stuck" or in 'U' state, it does come alive once in a while. The log below shows the 'U' state at 18:55:04, but then does not show up again until 18:55:49 (recall the script sleeps for 10 secs in between log entries). This time frame coincides with the time I was playing with (adding/removing) icons from the top menu bar.
I also tried "quitting" the SystemUIServer pid from Activity Monitor, but the process simply came back (with a new pid).

Mon Jan 12 18:54:54 MST 2009
PID TT STAT TIME COMMAND
780 ?? U 0:01.14 /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemUIServer -psn_0_405603

Mon Jan 12 18:55:04 MST 2009
PID TT STAT TIME COMMAND
780 ?? U 0:01.14 /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemUIServer -psn_0_405603

Mon Jan 12 18:55:49 MST 2009
PID TT STAT TIME COMMAND
780 ?? U 0:01.23 /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemUIServer -psn_0_405603

find unresponsive processes
 

open X11 and run xterm
or
run terminal

type in:
ps -axo state,pid,comm | grep ^U


"|" is the "pipe" - the character above the "\" on the right side of the keyboard.

stuck....but need definition
 

perhaps locked would be a better term?
Definition would be a process or child process is doing something critical to the use and/or stability of an application or event.

I'd be interested in a use case on what a kill -9 would do to a child process 'stuck' or related activity. maybe a less drastic stop or kill command?

I'd also like to know exactly what 'stuck' processes are.

While I got the idea from this discussion that they are likely temporary and not something to worry about, I didn't yet see a coherent explanation as to what they actually are (or did I miss it?).

Hoping someone can clarify what this term in top means.

TIA :)