Chapman Flack wrote:
> Garrett D'Amore wrote:
>> If I had a little more time, I'd go ahead and try to fix the kernel
>> grovelers myself.  I don't know how many of them are out there, but
>> there aren't many.
>
> egrep -rl '(getbootfile|kvm_openfiles)' /usr/src/*bin  turns up:
>
> sbin/savecore
> sbin/ccdconfig
> usr.bin/fstat
> usr.bin/ipcs
> usr.bin/netstat
> usr.bin/nfsstat
> usr.bin/pkill
> usr.bin/pmap
> usr.bin/systat
> usr.bin/vmstat
> usr.bin/w
> usr.sbin/ifmcstat
> usr.sbin/kgmon
> usr.sbin/mlxctl
> usr.sbin/ntp
> usr.sbin/pstat
> usr.sbin/trpt
> usr.sbin/trsp

We have enough people here to "just fix it" the right way.  I volunteer
to take the time to "fix" any two of these (*apart* from savecore, which
is special case, I think).  Someone else want to pick up a few?  If
eight more people offer to spend the ~1 hour required to make the
necessary changes, then maybe the grovelers can just go away.  (I can't
volunteer to do them *all*.)

Go ahead, tell me which ones folks think are most important, or are
hardest to change, and *I'll* fix them.  I don't have any particular
opinion myself.  "pkill" and "w" should be particularly easy, since I
doubt they need anything that "ps" doesn't already use.

    -- Garrett
>
>
> If there are any grovelers that don't actually use getbootfile
> or kvm_openfiles, they'll be in addition to the list above.
>
>> From experience, netstat usually misbehaves silently if it is looking
> at the wrong kernel, say by giving reasonable-looking but incomplete
> lists of listening sockets for -a. In netstat's case I confirmed that
> was the problem (and not, say, that I'd been rooted by some stealthy
> bugger) by getting the correct results after specifying the correct
> kernel.  I haven't systematically checked to see how all the others
> behave; of course one would prefer to get an error or obvious nonsense,
> but that seems very rarely to be what really happens.  (I first noticed
> the trouble with savecore when it was saying wd0a wasn't readable,
> which concerned me until I remembered that machine hasn't got a wd0a,
> and then concerned me a different way).
>
> My feeling's that a system known to ship with at least 18 kvm grovellers
> ought also to ship with a simple, prominently documented workaround
> for use cases where the grovellers would otherwise show heisenbehavior,
> and that it should ship that way for as long as it takes for sysctl to
> be extended with all of the internal interfaces needed by the >= 18
> grovellers, and for them to be rewritten to use it.
>
> -Chap


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191