tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: process mystery

In article <>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Fri, 25 Mar 2016 21:47:55 -0400
>    From:        "James K. Lowden" <>
>    Message-ID:  <>
>  | 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.



Home | Main Index | Thread Index | Old Index