Subject: Re: ps vs /proc
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 02/22/2000 10:13:19
>> The problem is, /proc *does* have a procfs mounted on it. Is ps
>> perhaps doing a getfsstat to see if a procfs is mounted there? My
>> kernel/user version skew is large enough that getfsstat() appears to
>> be returning trash.
> Mmm, strange. statfs() or struct statfs didn't change in ages, did it
It did. f_flags turned into f_oflags, with f_flags changing from a
short to a long (thereby growing the struct).
> Yes, ps's procfs fallback uses statfs() to be sure it's really
> talking to procfs filesystem.
>> Since the main use of the /proc fallback is dealing with
>> kernel/userland version skew, I submit that this is at best
>> suboptimal behavior; the fallback should be as robust as possible,
>> which in particular means that if it looks even vaguely like a
>> procfs it should be used, even if it seems dubious.
> Is there any other safe way to find out if the filesystem is really
> procfs without using statfs() ?
Does it matter? Why not use it anyway? If not having evidence it's a
procfs really bothers you, then print a warning that if it isn't really
a procfs there then the output is meaningless....
Offhand, I'd say that if it has a curproc link that readlink()s to the
current PID in decimal, it's close enough to be worth attempting.
> How old is your userland ?
Anything from before the struct statfs change will do. :) On the
system I noticed this on, I think most of userland dates from 1.4; I
think my 1999-08-13 source tree has a pre-change struct statfs too.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B