On Thu, Feb 24, 2000 at 01:22:25AM -0500, der Mouse wrote:
> > Hm.  Line 223 of procfs_ops.c does a strcmp of the returned
> > f_fstypename against MOUNT_PROCFS (defined in
> > /usr/include/sys/mount.h), which is what failed.  It might be
> > interesting, if you haven't already upgraded the whole system, to
> > have the warning print out what kind of filesystem it _thinks_ it is.
> > It'll probably just be "ocfs" or "fs"...  :)
> 
> Does this help?
> 
> [Truly-Delicious - root] 28> df
> Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
> /wd0a          10786456  2339952 11731952    16%    
>                       0        0        0    99%    
>                       0        0        0     0%    
>                       0        0        0 16268798%    
> [Truly-Delicious - root] 29> ps ax
> ps: proc size mismatch (24948 total, 744 chunks).
> ps: /proc exists but does not have a procfs mounted on it.
> ps: fallback /proc-based lookup also failed.  Giving up...
> [Truly-Delicious - root] 30> mount
> /wd0a on  type  (mounted by 20480)
>  on  type  (local)
>  on  type  (synchronous)
>  on  type /dev
> [Truly-Delicious - root] 31> 

  Hm.  If your kernel/user skew is so large that ordinary utils
like df and mount are busted, I don't think it is unreasonable
for ps to be busted.  Are there any sysutils that _aren't_ busted?  :)

  Of course, the proper course of action is to do a proper sysctl
that returns everything ps needs, in a carefully-constructed
format that is not directly tied to any internal kernel
structure layout.  That way, we'll never have problems ever
again.

  Any volunteers?  :)  I've been meaning to work on this for
months now, but don't envision I'll make any progress in the
next few months either.  :(
--
Brian Grayson