In Tue, 18 Aug 2015, James Harper wrote: > > 65961,9> ps axuf | grep D > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > root 35 0.0 0.0 0 0 ? S< Aug16 0:00 \_ [DWC > > Notificatio] > > root 1 0.0 0.8 5636 3664 ? Ds Aug16 0:20 /sbin/init > > ... > > > > Congratulations Poettering. > > > > Writing an init that gets stuck in the D state is a feat of magnificent > > incompetence. Tentacling it so badly into the rest of the system that the > > system can't proceed out of this state is just fantastic. > > > > Sorry... what? > > Unless I'm missing context somewhere, that's an awful lot of conclusions to > draw from one output of ps. In most of the cases I've experienced, a process > stuck in the D state is normally a result of extreme system load, a driver > fault, or a hardware fault (like a failing disk).
X got stuck. In a well designed system, this would result in any clients and dependencies of those clients also getting stuck. Not init. Why the fuck would init be doing anything other than wait()ing for zombie processes? -- Tim Connors _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
