Re: process mystery

[christos%astron.com@localhost (Christos Zoulas)]

In article <7088.1458975448%andromeda.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Fri, 25 Mar 2016 21:47:55 -0400
>    From:        "James K. Lowden" <jklowden%schemamania.org@localhost>
>    Message-ID:  <20160325214755.046f613b2866378396d60076%schemamania.org@localhost>
>
>  | I guess my only option is to send SIGKILL to the processes in DE state,
>
>That won't work, uninterruptible means what it says - the process is stuck
>in the kernel somewhere, you need to look and see what its wchan is
>(ps -l wiil show you) - My guess is you've hit a kernel lock bug (and
>wchan will be tstile).   Rebooting is the only way to clean that up, but
>provided that whatever is locked in the kernel isn't important to anything,
>you can also just leave it sit there forever - those processes won't use
>much in the way of resources.
>
>If you need to know what lock, you need to use gdb on the kernel and
>get a backtrace of the stuck process.
>
>You should be able to kill the xless (and xterm -e emacs) if you want,
>their ppid is already 1, so init should clean them up (unless you're
>suffering the lost zombies problem - which kernel version is this?)
>
>  | Does the utmp_update cascade suggest anything?  
>
>A process with a fork() bug probably.  But there are lots of possibilities
>(it is more likely the trigger for the stuck processes - more lock contention -
>than the other way around - that is, that the stuck processes caused all the
>utmp_update processes)   Do you know what the original parent of the 
>utmp_updates was ?

Or use crash(8) in the running kernel and t/t 0t<pid> of the stuck process.

christos

christos