[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: process mystery
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.
Main Index |
Thread Index |