Subject: Re: ps vs /proc
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Brian C. Grayson <firstname.lastname@example.org>
Date: 02/24/2000 01:38:33
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
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. :(