Re: process mystery

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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 ?

kre