lenny@icus.islp.ny.us (Lenny Tropiano) (12/18/88)
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:
"cp /dev/null /usr/adm/unix.log" and I haven't seen an error since. Is
this good sign or not?! I used to get Spurious interrupts from my
printer, and FDERR's sometimes when formatting diskettes. I can't even
induce errors when I want to. (ie. opening the floppy do when formatting?!)
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?
# ls -l /usr/adm/unix.log
-rw-r--r-- 1 root root 0 Dec 5 19:38 /usr/adm/unix.log
-Errorless and 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 11752lenny@icus.islp.ny.us (Lenny Tropiano) (12/20/88)
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
jbm@uncle.UUCP (John B. Milton) (12/22/88)
In article <557@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >Did I do something wrong?! Of course! :) [ no errors in /usr/adm/unix.log ] >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, ^ `--SINCE WHEN?!!! At least as far as the 3.51 smgr goes, whenever a log file gets over 10k, the smgr re-opens with O_CREAT, so if you get lots of errors, you'll lose them whenever the log file gets too big. I do this from cron every night: cd /usr/adm if [ -f unix.log ]; then cat unix.log >> UNIXLOG rm unix.log fi Another thing some people might miss here: Whenever the kernel want to send messages to the outside world, it uses a kernel routine eprintf(). This writes a line of text to /dev/error. While the smgr is sitting around doing nothing, it has a read hanging on /dev/error. Certain line formats will do different things when smgr reads the line: echo "#This will go to /usr/adm/unix.log" > /dev/error ^ `-- This tells smgr that this is an error to be logged. echo "This will go to the [!!] icon" > /dev/error There are other formats to get to the [!], fuel gauge, mail, and calendar icons. There are also some MAJOR security holes here, if you know the right format line to write to /dev/error. Several things will break if you write protect /dev/error, so that's not a good solution. I was thinking of posting a complete doc on all the strings you can send to smgr through /dev/error, but now I don't know if I should until a patch to smgr can be developed. Any thoughts? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?