Re: [PATCH] Cosmetic changes to boot-up sequences

Todd Graham Lewis (tlewis@mindspring.com)
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