Path: utzoo!utgpu!watmath!uunet!ukma!rayssd!icus!lenny
From: lenny@icus.islp.ny.us (Lenny Tropiano)
Newsgroups: unix-pc.general
Subject: Re: Error logging to /usr/adm/unix.log ceased?!
Summary: Some more information...
Keywords: errors, logfile, /usr/adm/unix.log
Message-ID: <559@icus.islp.ny.us>
Date: 19 Dec 88 18:49:07 GMT
References: <557@icus.islp.ny.us>
Distribution: unix-pc
Organization: ICUS Software Systems, Islip, New York
Lines: 60

In article <557@icus.islp.ny.us>, lenny@icus.islp.ny.us (Lenny Tropiano) writes:
> Did I do something wrong?!   I used to get errors in my /usr/adm/unix.log.
> I cleared it out in the beginning of the month with:
> 
...
> I'm concerned that something is screwed up.  Maybe it's because I'm
> running UNIX3.51c, maybe not.  Is there a way to start things fresh,
> maybe remove the file?  Will it be created when the first error occurs?
> 
...
Well here's a little more information.  I thank those who promptly
replied.  Change the permission on the /usr/adm directory or /usr/adm/unix.log
didn't seem to change the results.  Even after a complete reboot.
This shouldn't matter since /etc/smgr is run as "root".  I rather have
certain things securely protected from people just removing them with:

$ > /usr/adm/unix.log

World writable isn't the answer...

I know understand how the error scheme on the UNIX pc is handled.  It seems
to be handled by /etc/smgr.  (Of course I was running it, so that wasn't
my problem).  What happens the kernel will write a message to /dev/error,
and /etc/smgr will read /dev/error.  If the message is prepended with a
"#", it will be logged to /usr/adm/unix.log.

Here's a list of the errors trapped by /etc/smgr from the kernel that
would/could be written to /usr/adm/unix.log (from string table).

#NMI (parity error in unmapped page) at 0x%x (*hpte: 0x%x)
#NMI (parity error) at 0x%x (*hpte: 0x%x)
#Spurious NMI (ignored)
#Spurious interrupt - level %d
#Inode table overflow
#out of text
#pid %d: killed on swap error
#FD:Spurious interrupt
#HD:Spurious interrupt
#FDERR:timeout
#drv:%d part:%d blk:%d rpts:%d
#baddma:%x
#FDERR ST:%x TR:%x SR:%x DR:%x DMACNT:%x DCRREG:%x MCRREG:%x
#HDERR ST:%x EF:%x CL:%x CH:%x SN:%x SC:%x SDH:%x DMACNT:%x DCRREG:%x MCRREG:%x

I tested the fact that my errors are still working, although I cannot
physically generate any of my own.  I did a:

$ echo "#Test logging" > /dev/error

And the message got logged to /usr/adm/unix.log.   All is safe then ...
3.51c isn't the culprit.  I don't know why I cannot generate any more 
errors, but I guess this is good?!   Or isn't it?

						Still a little concerned,
						-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny@icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752