DragonFlyBSD

:hi folks,
:
:sometimes sysctl or fstat just stop and end up as a zombie process
:
:% ps
: PID TT STAT TIME COMMAND
: 81 #C1 SL 0:00.04 _su -m (csh)
:40884 #C1 IWL 0:00.00 sysctl
:41510 #C1 DWL 0:00.00 sh -c /usr/bin/fstat > /dev/null 2>&1
:41513 #C1 ZL 0:00.00 /usr/bin/fstat
:53544 #C1 IWL 0:00.00 sysctl
:53549 #C1 IWL 0:00.00 sysctl
:53647 #C1 DL 0:00.01 sh -c /usr/bin/fstat > /dev/null 2>&1
:53648 #C1 ZL 0:00.00 /usr/bin/fstat
:53651 #C1 DL 0:00.02 sh -c /usr/bin/fstat > /dev/null 2>&1
:53654 #C1 ZL 0:00.00 /usr/bin/fstat
:57387 #C1 R1L+ 0:00.01 ps
:
:I can't kill them, even with kill -9
:
:so my question is, ignore them or is smth broken?

Well, fstat can seg-fault trying to access kernel memory.  The
    question is why aren't these zombies being reaped by their parent.

If you generate a kernel core dump with the system in this state
    and upload it to leaf I'll try to track it down.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matt suggested turning off the mpsafe sysctl's (they're turned off by
default) and this worked, no more zombie processes, no more strange
netstat -m output, no systat -ifstat errors

:..
:> Well, fstat can seg-fault trying to access kernel memory. The
:> question is why aren't these zombies being reaped by their parent.
:>
:> If you generate a kernel core dump with the system in this state
:> and upload it to leaf I'll try to track it down.
:Matt suggested turning off the mpsafe sysctl's (they're turned off by
:default) and this worked, no more zombie processes, no more strange
:netstat -m output, no systat -ifstat errors

Right.  The mpsafe sysctls are experimental.  I put them in there so
    we could start identifying areas that need work, and we've identified
    probably half a dozen issues so far.  They aren't turned on by default
    and so will not effect the release.  The areas in question, along with
    other goodies, are going to be worked on after the release.

In the case of fstat the issue is simply the process p_lock counter
    being accessed without appropriate MP protection.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

is this fixed?

:Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:
:
:is this fixed?

I think this one is fixed.  Hopefully all the lockf related bugs have
    been fixed now.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

sry for replying so late

yes this bug is fixed and the issue can be closed

thx