NEWS for version 1.01 of procps -*- text -*- top bugfix release. Fixes memory leak, extra line after loadavg and broken no-idle mode. Also be a little more aggressive utmp 'from host' filtering in w. NEWS for version 1.00 of procps Fixed the ps -t without a -a segfault bug. Royal screwup on my part. Updated libproc parsing routine for the new vsize output as of 1.3.91-ish. Expanded the room for the FLAGS in ps -l due to high order bits now being set. Added a brand new top to the distribution. Highly run-time configurable. The old top is available for at least a release or so as "top.old". See the new man page for details, or just run it and type 'h'. This is courtesy of Helmut Geyer. Thanks Helmut! egrep -n '\<(tgetent|cm|top_clrtoeol|top_clrtobot|cl|ho|me|md|mr|tgoto)\>' on top.c and cleaned up all terminal strings being just dumped to stdout. All such strings are now tputs'd out with putchar. This should fix a lot of problems people have been having. Also cleaned up non-HZ based references to jiffies -> real time conversion. I may have missed one or two, though... Cleaned up some Makefile things. make distclean; make should really work now. removed function pointer warnings in xcpustate.c. .depend is properly removed as are the imake generated makefiles. Shared lib generation bug for libproc fixed. In general the build should be a lot cleaner, but may still have a glitch or two. Fixed a few (but probably not all) Alpha compatibility bugs dealing with memory alignment. Please let me know if I missed any, or if you like give me a test account on some Alpha. I don't have access to any Linux other than x86 which is notoriously forgiving about unaligned memory accesses. Thanks to Alfred Arnold (a.arnold@kfa-juelich.de) and Harald Koenig for their help so far with this. Completely (well almost) re-wrote 'w'. From on by default, J/PCPU display is accurate to 0.01s. w and top use readproc, so snap.c has gone away completely. 'skill' should actually work now, but you may have to use '-c', '-u', etc. to actually get it to parse the command line correctly. *** Significant changes in psdevtab inverse device name resolution ------------------------------------------------------------------ Extended semantics of the -n (numeric) option to output the full device number in hexadecimal for the tty field. That way if /etc/psdevtab cannot be created rescanning the /dev directory can be short-circuited. Fixed incorrect file creation mode for /etc/psdevtab. I just forgot to alter my original 0 mode to something reasonable like 0664. Added fallback locations for psdevtab. First it tries /etc/psdevtab, then /tmp/psdevtab and then $HOME/.psdevtab. Also, decided to go ahead and create the devtab file with regular old write instead of the rw mmap. I still read it with mmap, but there should be no trouble with that even in ancient kernels. Also changed the semantics such that if any devtab file is found, it is assumed to be correct regardless of the relative timestamps of /dev and the file. Hopefully all this will avoid any unnecessary slowness. I'm still willing to reactivate the older somewhat broken code to do the mapping without any file as a fallback if the file doesn't exist. *** Significant changes in psdatabase/WCHAN inverse name resolution ------------------------------------------------------------------- libproc reads directly from System.map, so psupdate and /etc/psdatabase are no longer necessary. Hopefully this will make kernel configuration management simpler requiring only the zImage and System.map, which being the stripped (compressed) kernel and the symbol table before stripping are natural complements. This is probably how things should have been all along even going back to kmem ps days four years ago. Oh well. This change should make dealing with x86, AXP, Sparc, etc binary formats for kernels a lot easier. All that is required of System.map is that there be exactly 3 space delimited columns: "address[single space]anything_with_no_spaces[single space]symbol[newline]" [ Well, ok, the addresses have to be zero padded so that lexicographic order is the same as numerical order and the addresses all have to be the same ascii length and I haven't tested to see how resilient it is to bogus internal records like multiple newlines in a row. Hopefully aren't editting and commenting their System.map files. ;-) This could actually work on "sort < /proc/ksyms" also if we generalize the behavior to work with either two or three columns. ] We take advantage of the following files in this order: PS_SYSTEM_MAP # may only point to System.map, not psdatabase /boot/System.map-`uname -r`, # Note: this is the preferred path /boot/System.map /lib/modules/`uname -r`/System.map /etc/psdatabase /boot/psdatabase-`uname -r`, /boot/psdatabase, /lib/modules/`uname -r`/psdatabase The reason for the /lib/modules/*/file location is that I imagine many people have enough trouble keeping track of kernel version-dependent files in the filesystem as it is, so I didn't want to invent a new place. I keep things in /boot myself and don't usually have more than 8 or so kernel versions, so this works for me. I know not everyone uses modules, but it's just a search path folks... In case it isn't obvious from all of the above, this means that psupdate is no longer necessary. I include it in this release and include recognition of it because I realize that some distributions may have scripts which depend on the old semantics. I doubt there will ever be a compelling reason to not include support for generating or reading the old psdatabase files, but they aren't necessary anymore if you have the System.map files from the kernel builds. I'm not 100% sold on the ordering of the search path, but I think it makes sense. If you have reasons why it should be different I may be convincable. Also I'm interested in exactly what the output of 'nm' looks like on Alpha, Sparc, etc., architectures. It should be easy enough to adapt the code if it is basically the same format of <0 padded hex> ... \n. Thanks to Helmut Geyer for the idea of living off the System.map file natively and Mike Dean for the idea of using an approximate binary search instead of padding out the lines of System.map with tons of spaces to get equal record lengths. The cost of doing it approximately is mild, mostly consisting of lots of scans to get to the next or last newline and a logarithmically few extra steps to get to the desired record. Only an order of magnitude guess for the record length is necessary. The code is all mine, though, so all bugs are due to me alone. NEWS for version 0.99a of procps ================================ This is a quick bug-fix release to solve a few thorny problems with my probably overzealous attempt to use the inline-assembly string.h and a Makefile bug or two. It also fixes free to +/- the cached column too and makes it ignore the new extra-pretty non-numeric lines that /proc/meminfo is spitting out. It also fixes the lack of set_linux_verion() in 'w' that caused no command line to be displayed. I am still working on a much condensed 'w' that should be a lot easier to maintain and a readproctree that should be usable by both 'ps', 'pstree', and 'w'. Apparently memory-mapped files are pretty broken before the early 1.3.X kernels so I may have to rewrite devname.c to not use MAP_WRITE to create psdevtab. Some people have been claiming that /dev changes at boot-up in some rc scripts. I'm not really sure why they would want to do that. Seems kind of paranoid to continually re-make /dev/log. Anyhow, I'm open to suggestions for psdevtab behaviors. I've been thinking a /tmp/psdevtab fallback (with a careful world readable umask to avoid repetition) or maybe a $HOME/.psdevtab fallback too. NEWS for version 0.99 of procps =============================== This file is a brief catalog of new features or developments in the package. For general information about using the programs see their man pages. NEW PACKAGES OR PROGRAMS ======================== LIBPROC I've modularized some routines and fixed some long standing bugs. Replaced the regex() recognition of /proc/PID with a simple check of the first character of the filename being a digit which should be just as safe. Added an opendir/readdir/closedir style interface to the process table. The new interface seems cleaner, more intuitive and generally more applicable (to me anyway). The only program which uses the new interface is ps. 'w' will follow soon. 'top' may take a while longer... openproc,readproc, and closeproc are implemented. I still want to do readproctab and rewindproc, too though. Added some kernel and package versioning things to make it easier to be run time adaptable. Also updated sysinfo to understand any /proc/meminfo. A /proc/stat parser should probably be in there as well with the appropriate updates to vmstat and xcpustate. The general direction procps should move in is lightweight command-line or X11/Motif display/format programs and compartmentalized libproc routines to parse all of the /proc files. This isolates the utilities from kernel versioning. TTY DEVICE NUMBER TO NAME RESOLUTION Tty device name <-> number mapping has been completely generalized. It now stat's every character special file in /dev and builds a memory mapped table of device names indexed in a way that makes lookup of name from number a fast, constant time process. The extra overhead incurred by building /etc/psdevtab is non-negligible if you have a large /dev and permissions to write the file (or its directory) are required to update the file (which is done if it does not exist or if /dev is newer than /etc/psdevtab). Hence `root' should `ps' shortly after any modification to /dev (or chmod 666 /etc/psdevtab :-) to avoid ordinary users rebuilding it over and over. Since such modifications are rare, hopefully having a fallback $HOME location will not be necessary. If the file is up to date, the overhead incurred is very small. The generality bought is essentially optimal since `ps' tailors its notion of name<->devno mapping according to the /dev of the local system which is the canonical repository of this information. In principle the name database could encompass all device majors. The file would be large, but since I use mmap to access it, only the pages with the major of interest are ever actually read off the disk. Right now I just use the majors 2,3,4,5,19,20 which should cover both old and new systems with both master and slave devices (I know... no reason for the masters... :-) and the multiport serial devices. Also the 'mknewpty' script is provided to update your /dev directory to the new pty master/slave devices. The tty abbreviation scheme has been rationalized to match device special files. The leading "tty" or "cu" is stripped, so cua3 -> a3, tty1 -> 1 and ttyp9 -> p9. The t flag in ps now works with a full device names and to pick up processes even if they aren't owned by the owner of ps, e.g. "ps tcua0" picks up gpm for everyone. This seems desirable. WATCH A little program similar to another called 'vis' which simply re-displays in a polling fashion the output of other programs. "watch ps --sort:utime" might be dubbed a poor man's 'top'. Though this has been included in procps for some time it hasn't been built or installed by default. It is now. SKILL/SNICE I have written the necessary machine-dependant file for 'skill' and tested it somewhat under Linux. It seems to mostly work, but there are probably a few glitches. This is a generalization of the 'killall' concept. You can send signals or change priority based upon user, command basename (the same that 'ps c' gives), terminal, etc. If you have a user named 'satan' "skill -u satan" will kill all their processes. :-) See the man page for more details. An annoyance of the current implementation is that although permission to send signals is based upon the real user id, /proc only gives the effective uids of processes. Hence processes which you *could* kill because they're suid-root (X say) won't be detected as kill-able. Either /proc + readproc need to be updated to report the *real* uid to skil or skill needs to try to send the signal even if the uid doesn't match. XCPUSTATE This is basicly a unified memory/cpu/network monitor program courtesy of Andy Burgess (aab@cichlid.com). It shows four bars in a window with the current usage of various system resources. PSMISC PROGRAMS See the files under psmisc. These files apply to killall, pstree, fuser. The version included here is 0.11. I accidentally put the 0.9 version in an unadvertised stealth 0.98 release. Sorry Werner :-) CHANGES TO OLD PROGRAMS ======================= MAKEFILE The directory hierarchy has been restructured. It is now easier to have the multiple components to the suite under nearly autonomous administration. The library code has also been moved to a subdirectory. The best thing about the new setup is that things like Imake generated Makefiles with preconceived notions of 'make install' can be used without getting into the business of re-writing component package makefiles. There is now an option to build a shared libproc.a which reduces 'ps' and 'top' sizes by about 10K apiece. Simply change the value of SHARED. Also, one may optionally install the library header files and archive/shared object files into standard system directories. There are no library man pages yet, but the headers are fairly descriptive. PS Several long standing bugs have been fixed and much of the internal code was re-written to use my new directory-style interface to the process table. In particular if sorting is disabled (with '-o') the process entries are output to the terminal as soon as possible (making it more helpful under heavy system load). I am considering several new additional features to `ps' including regex filtering of which processes to list, "grep -s" silent testing for existing of processes matching criteria, run-time/user-defined output formats. I would also like to completely phase the w,top code which uses the snapshot interface instead of the 'readproc' interface. And of course adding long options for the rest of the options would be nice too (I may not get around to doing this anytime really soon so patches which implement any of these things would most likely be gleefully accepted). PSUPDATE psupdate has been updated to work with ELF kernels. If you compile it as an ELF binary it will handle both a.out and ELF kernels. If you compile it as an a.out binary it will only handle a.out kernels. Many thanks to Jeff Uphoff. TOP A user-defined format would be nice here too. Alternate sorting criteria (top memory users instead of top CPU users, etc.) may be another interesting alternative. Of course the sorting in ps can do all of that, but it doesn't have any optimal screen update action going down... :-) XLOAD/XIDLE/XMEM These have all been updated to use the sysinfo.c routines from libproc and so will be more resistant to /proc format changes.