Errors in PS

[Guy Harris]

>It appears that ps needs to do i/o on /dev/swap in order to fill in some of
>the fields it needs, depending on the state of the process it's listing.
>Exactly why this should be true on a 386, which *OUGHT* to be a paging system
>rather than a swapping system, I can't say,

The name "swap" in "/dev/swap" is, in part, historical.  In many paging
UNIX systems, "/dev/swap" refers to the area where pages (or, at least,
pages not directly backed by blocks in a file) get written if necessary.
(On some systems it may be known as "/dev/drum" instead, which is, these
days, a historical name as well - did any BSD release *ever* use a drum
as a paging device?  Did DEC ever *sell* a drum as a PDP-11 or VAX
peripheral?)

In addition, paging systems *do* swap, on occasion; if there are two
many processes swapped in and competing for physical page frames, your
system will thrash.  Paging systems may "swap out" processes, which will
mark them as not eligible to be run, in order to prevent this from
happening.

Some of the information about the process that "ps" wants to print is
stored in a region called the "U area", which tends to be swapped out
when the process is swapped out

>I believe even on a paging system it pages out to /dev/swap, or the
>like, right?

Right.

>Could it be that the paging code somehow stepped on the toes of an lseek ps
>was doing on /dev/swap?

It could be.  To quote from the BUGS section of the SunOS 4.0 PS(1)
manual page:

     Things can change while ps is running; the picture it  gives
     is only a close approximation to the current state.

This appears in other PS(1) manual pages as well; I think it may date
back to V7.

>The way that ps works is an utter abortion, IMHO.  Many, many, many operating
>systems have a system call to yield up process table entries.

Some versions of UNIX have a better mechanism for this than either the
current mechanism *or* a system call.  They have a fake "file system"
mounted on the directory "/proc".  In this directory appear files with
names that are ASCII versions of process IDs; for instance, "/proc/1" (I
don't know if they have leading zeroes or not; I'm assuming they don't,
here) is the file for the "init" process.

You can open this file if you have permission (as I understand it, the
file appears to have, as its owner and group owner, the effective UID
and GID under which it's running, and to have permissions "rw-------",
so only the UID under which it's running or the super-user can open it).
You can read or write the file to read or modify the address space of
the process; you can issue various "ioctl"s to control the process -
stop it, start it, catch various signals, read its U area, etc..

This can serve as a replacement for "ptrace", of course.  It can also
serve as a mechanism that "ps" can use.