michael@stb.UUCP (Michael) (09/19/88)
I just discovered /usr/adm/unix.log Questions: #1. Does the system verify writes to the hard drive? #2. How many repeats will the system take before it considers the read to fail? (If it takes 10 tries, I won't consider my repeats of 1 to be a problem) #3. Why doesn't a surface check find these? #4. Is there any way to get these mesages into a more noticable place (such as SMRG's message queue?) Michael p.s. If the system doesn't verify writes (to both floppy and hard), how can we/I make it verify them? : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
kevin@kosman.UUCP (Kevin O'Gorman) (09/20/88)
In article <10585@stb.UUCP> michael@stb.UUCP (Michael) writes: >I just discovered /usr/adm/unix.log > >Questions: >#1. Does the system verify writes to the hard drive? >#2. How many repeats will the system take before it considers the read to >fail? (If it takes 10 tries, I won't consider my repeats of 1 to be a problem) >#3. Why doesn't a surface check find these? >#4. Is there any way to get these mesages into a more noticable place >(such as SMRG's message queue?) Well, here's the shell script I run every night from /usr/lib/crontab. It saves the log daily, keeping a week's worth, and mails the daily segments to root, so that you actually see this stuff. It could be made lots better with some massaging, a la perl, but this at least lets me see what's what. # /usr/local/bin/trimlog # if this is run once per day, it will save the last # weeks worth of hardware error-log files. You can, of course, comment # out some of the lines to save less cd /usr/adm mv ulog.5 ulog.6 mv ulog.4 ulog.5 mv ulog.3 ulog.4 mv ulog.2 ulog.3 mv ulog.1 ulog.2 mv ulog.0 ulog.1 mv unix.log ulog.0 cp /dev/null unix.log if [ -s ulog.0 ] then (echo "Contents of unix.log:"; cat ulog.0) | /bin/mail -t root fi > Michael >p.s. If the system doesn't verify writes (to both floppy and hard), how can >we/I make it verify them? >: --- >: Michael Gersten uunet.uu.net!denwa!stb!michael >: sdcsvax!crash!gryphon!denwa!stb!michael >: Coff Coff <=== Stop smoking.
cals@cals01.zone1.com (Charles A. Sefranek) (09/28/88)
I too have some questions about /usr/adm/unix.log
I have noticed some strange behavior with this file on my machine. I have
a 3b1 with 67M disk, 2M RAM running 3.51 (the 3.51a fix is in, but it didn't
make a difference).
Assuming a healthy unix.log file with lots of FDERR entries from the last
time I formatted floppies -- if I start a new formatting session (ten or
more disks) then check the unix.log file when done, all the previous entries
are gone and only new FDERR entries (dated within minutes of finishing) exist
in the file!!!
My question is: Has anybody else noticed this??? Does anyone know what in
the world is causing this ?
Please email and I will summarize to the net. Thanks in advance.
--
Charlie Sefranek c4s@rayssdb.ray.com (Work)
cals@cals01.zone1.com (Home)
{sun,cb-att,decuac,gatech,necntc,ukma}!rayssd!rayssdb!c4s (Work)
{sun,cb-att,decuac,gatech,necntc,ukma}!rayssd!galaxia!cals01!cals (Home)
--
--
Charlie Sefranek c4s@rayssdb.ray.com (Work)
cals@cals01.zone1.com (Home)
{sun,cb-att,decuac,gatech,necntc,ukma}!rayssd!rayssdb!c4s (Work)
{sun,cb-att,decuac,gatech,necntc,ukma}!rayssd!galaxia!cals01!cals (Home)