kevin@msa3b.UUCP (Kevin P. Kleinfelter) (07/20/89)
sar and sag have mysteriously broken on my AT&T 3B2/700. Actually, it is not sar and sag, but "sadc", which does the data collection. When the system boots, sadc is automagically started. It creates a file /usr/adm/sa/sa?? (where ?? is the day of the month). If I do a sar, it reports "UNIX restarted". However, the file is never updated again. sadc used to update this file regularly, and automagically switch to the next day at midnight (sa?? + 1). If I manually run sadc, I get an additional "UNIX restarted" line in sa??, but there is no sadc reported in "ps -e", so I conclude that it updated sa?? and died. I do not know exactly when this stopped working. Any ideas? "sar" and "sag" are documented very nicely in my manuals, but there is NO doc for "sadc". :-( -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin
pgn@cbnewsc.ATT.COM (Novorolsky) (07/26/89)
kevin@msa3b.UUCP (Kevin P. Kleinfelter): > sar and sag have mysteriously broken on my AT&T 3B2/700. > > Actually, it is not sar and sag, but "sadc", which does the data > collection. When the system boots, sadc is automagically started. > It creates a file /usr/adm/sa/sa?? (where ?? is the day of the month). > If I do a sar, it reports "UNIX restarted". However, the file is > never updated again. > > sadc used to update this file regularly, and automagically switch to the > next day at midnight (sa?? + 1). If I manually run sadc, I get > an additional "UNIX restarted" line in sa??, but there is no sadc reported > in "ps -e", so I conclude that it updated sa?? and died. > > I do not know exactly when this stopped working. Any ideas? "sar" and "sag" > are documented very nicely in my manuals, but there is NO doc for "sadc". :-( > > -- > Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 > gatech!nanovx!msa3b!kevin ( I tried to mail this, but it bounced......) The manual page for SADC is included in the SAR(1M) manual page in the System Administrator's Reference Manual. (The is also a SAR(1) page in the User Reference Manual, but this is for the SAR reports) (Please no flames on where things are in the manual. That is why the permuted index exists.) SAR(1M) also gives a couple of examples how to use the sa1 and sa2 commands (both in /usr/lib/sa) It includes a few examples. The sadc command must be restarted periodically to collect data over a specified time. The manual pages show how to set up a crontab entry to sample over 20 minute intervals. To try it, invoke "/usr/lib/sa1 1200 3". The 1200 specifies a sample every 20 minutes (20 * 60 = 1200), the 3 tells it to take 3 samples (so that the command covers 1 hour) If these commands (sa1, sa2, sadc) are truly not on the system (they should all be in /usr/lib/sa) send me mail and I will find out where you should be able to find them. (be sure to let me know what release of Operating System you have (output from uname -a).) ======================================================== **paul novorolsky ( !att!iwtpm!pgn, pgn@iwtpm.att.com, attmail!pnovorolsky) ========================================================
jrw@mtune.ATT.COM (Jim Webb) (07/26/89)
Re: sar and sag have mysteriously broken on my AT&T 3B2/700.
My first inclination would be to check the crontab entries.
What should be going on is the running of /usr/lib/sa/sa1 every
so often. It is a shell script that calls sadc. Here, they
look like:
/usr/spool/cron/crontabs/sys:0 * * * 0,6 /usr/lib/sa/sa1
/usr/spool/cron/crontabs/sys:0 8-17 * * 1-5 /usr/lib/sa/sa1 1200 3 &
/usr/spool/cron/crontabs/sys:0 18-7 * * 1-5 /usr/lib/sa/sa1 &
They are not all that mysterious, the most important one is the
second, which means to data collect for 20 minutes (1200 seconds)
3 times. This is done during prime time (8-5 each weekday). These
are probably not what is shipped with the floppies, we don't run a
stock shop here.
If they look alright, then the next place to look is in a file
called /tmp/sa.adrfl. This is the sadc address file. When sadc
starts up, it creates this file and puts the various memory addresses
it needs in it. This way, it does not need to do a namesearch on /unix
each time. Saves time, sort of like ps and /etc/ps_data. Anyway, if
for whatever reason, this file is corrupted, sadc won't work. It
will just do nothing :-) So, remove this file and try again. One
easy way to test it at this point is to say "sar 2 4" which will give
you a 2 second snapshot of the system 4 times.
As for documentation for sadc:
sadc.c - writes system activity binary data from /dev/kmem to a
file or stdout.
Usage: sadc [t n] [file]
if t and n are not specified, it writes
a dummy record to data file. This usage is
particularly used at system booting.
If t and n are specified, it writes system data n times to
file every t seconds.
In both cases, if file is not specified, it writes
data to stdout.
Hope this helps out with that question!
Re: layers hangs my terminal
| I'm running layers on an AT&T 3B2, with Sys V R3.2.1, and an AT&T 630 tty.
| I'm pretty pleased, but there is this problem...
Well, I like the one I am typing on a lot, too :-) Anyway, I don't know how
what you are experiencing could be happening. Granted, I *believe* it is
happening, mind you, but I just think something is missing somewhere. You
say that you:
| login successfully
| start layers
| do inconsequential stuff [like break sar and sag :-)]
| ^D (without leaving layers)
and then are dead in the water. At this point, you should be able to just
create a new window. Granted, the current window will indeed be dead. But,
after creating a new one, you will be able to delete the first one. I really
don't know why the terminal would still be dead after a power on and off (it
will be really dead after killing all the processes :-). How many xt devices
do you have defined? That would be #DEV in /etc/master.d/xt. You might be
running out there, since you say you need a reboot. Each dev corresponds to a
terminal, not a window, so, if you have 8 devs, you can have 8 terminals on
your system.
You also asked:
2) How can I tell (in a shell script) if layers is active on my tty?
(If I can set my prompt string, PS1 to say "LAYERS" I can
avoid trying to logout while layers is running.)
Well, after layers runs, you are no longer on a tty port, but rather an xt
port. So, I would do a tty command and look at it and if it says xt???, set
your prompt accordingly. Eg:
if tty | grep xt >/dev/null
then
PS1="LAYER$ "
fi
Since you are running ksh, you could also say:
set -o ignoreeof
which would blast out at you:
Use 'exit' to logout
whenever you typed '^d' at the window. I use this myself.
Well, I have pontificated long enough. I hope this helps out!
--
Jim Webb "Out of Phase -- Get Help" att!mtune!jrw
#include <std/disclaimer.h> jrw@mtune.att.com