Messages in this thread |  | | From | Todd Graham Lewis <> | Subject | Re: [PATCH] Cosmetic changes to boot-up sequences | Date | Mon, 15 Jul 1996 21:34:47 -0400 |
| |
On Mon, 15 Jul 1996, Theodore Y. Ts'o wrote:
> Date: Sun, 14 Jul 1996 22:03:53 -0700 (PDT) > From: Khan Klatt <khan@pacificrim.net> > > I'd like to see something like a "Linux Logging" campaign... > > The end result is to get Slackware and RPM packages of software which > by default, log everything in /var/log: > > What you're talking about is only a small part of what is said by the > Linux FSSTND (filesystem standard). Applications and distributions > which are FSSTND complaint will be logging into /var/log. > > Been there; done that. :-)
True, "Where do I put log data" is a solved problem.
What about some sort of formalized event reporting for significant events, such as shutdowns, panics, etc., ala UERF?
While we have you here, Ted (8^), how close are we to being able to implement a 'sar' and 'sysctl' command? I ask from curiosity. A lot of the statistics which sar and sysctl report, and esp. sar, I can't figure out how we'd do under the present kernel design. Am I wrong, or is it not there? If not, then how soon might such features be implemented? E.g., (shamelessly stolen from the sar man page):
- FS cache hits/misses - buffer transfers per second - syscalls, forks, execs, reads, writes per second? - pages in, out, freed, scanned per second? - semaphore activity (from fstat under bsd) - open files, with controlling process, user, pid, etc.
A lot of this I am sure that we can do presently. Again, /proc/sys seems designed to address a lot of these issues. Still, the entirety of /proc/sys doesn't compare to sysctl under bsd, much less sar and friends. Are there man pages I am not reading, and if so, which ones? (I already have my own version of sysctl which reads from /proc/sys, but usually an snmpwalk is more productive. 8^)
I am trying to get a feel for where we stand on this front. I recall some discussion of this from last Feb (??), and I thought I'd check back in on it.
Any feedback the developers could give on these quesitons is very welcome.
_____________________________________________________________________ Todd Graham Lewis Core Engineering Mindspring Enterprises tlewis@mindspring.com (Standard Disclaimers) (800) 719 4664, x2804
|  |