linux-kernel - defunct processes owned by init, not being reaped ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4C658D66.3020801@genband.com>
Date:	Fri, 13 Aug 2010 12:22:30 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	linux-kernel@...r.kernel.org
Subject: defunct processes owned by init, not being reaped ?

I'm seeing something very strange.  I've got a system running a modified
2.6.27.18.  There are two tasks that are showing up as defunct but owned
by init:

root@...hoon-base-unit1:/root> ps -ef|grep defun
root    9933   1  0 09:05 ?   00:00:23 [oamFmLogServerP] <defunct>
root    9959   1  0 09:05 ?   00:00:21 [oamFmCliServerP] <defunct>
root   27674 17021  0 18:17 pts/2  00:00:00 grep defun

I tried sending init a SIGCHLD to force it to reap them.  Init tries to
wait for any children, but it doesn't catch them and they remain
defunct--here's the strace of init:

stat64("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat64(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
stat64("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
select(11, [10], NULL, NULL, {5, 0})    = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, 0xffcbf6ac, WNOHANG)        = 0
sigreturn()                             = ? (mask now [])
time(NULL)                              = 1281723340

Anyone got any ideas what could possibly result in this sort of behaviour?

Thanks,

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@...band.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/