On Sat, 26 Mar 2016 13:57:28 +0700 Robert Elz <k...@munnari.oz.au> wrote:
> Date: Fri, 25 Mar 2016 21:47:55 -0400 > From: "James K. Lowden" <jklow...@schemamania.org> > Message-ID: > <20160325214755.046f613b2866378396d60...@schemamania.org> > > | 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) Thank you for your analysis. It took awhile to get back to this, but the situation hasn't changed. $ ps -l -p 3419 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1000 3419 1 0 0 0 0 0 - DE ttyp9- 0:00.00 (utmp_update) I don't know what wchan is, apart from what the ps manpage says. Looks like it's waiting on event "-", which would seem to support your "stuck" theory. > If you need to know what lock, you need to use gdb on the kernel and > get a backtrace of the stuck process. I don't need to know the kernel status unless someone here is curious. I'm mostly interested in understanding my options short of rebooting. > | Does the utmp_update cascade suggest anything? > > A process with a fork() bug probably. OK, nothing I did then. :-/ > Do you know what the original parent of the utmp_updates was ? No. I was fooling around with various forms of "xterm -e", and I suspect xterm hosted the original ppid, but I'm not sure. Regards, --jkl
