russell@ucb-vax.ARPA (08/22/85)
It appears that something went wrong during an invocation of
"/usr/lib/sendmail".
A C-shell user used the "mail" command ("/usr/ucb/mail"). An error
message was printed, and the user says that it was something to the
effect of "table overflow". The user found herself in root's directory
and did a "cd" to get back to hers. She then re-issued the "mail"
command, and got the same error message.
As it turned out, the "to" address she specified was invalid, so the
mailer daemon returned the mail. However, only one copy of the
undeliverable mail message appeared in "root's" mail box. The other
copy appeared in the user's own mail box. Presumably, the one in the
user's mail box was the result of the first "mail" command, and the
one in "root's" mail box was the result of the second "mail" command.
We theorize that whatever caused the problem in "sendmail", left the
user running as "root". Since "mail" doesn't run setuid-ed to "root",
and our "sendmail" does, it is "sendmail" that we suspect.
If our theory is correct, then that is a problem in and of itself, but I
am having trouble reconciling that theory with the way that I understand
the C-shell to operate. Since the C-shell forked the invocation of "mail",
when that child process terminated, and when execution resumed in the
C-shell, all should have been as it was. The C-shell should have been
executing as the user, not as "root".
The system on which this occurred is a Sun Model 120 running Sun Unix
4.2 Release 1.1.
Following is the returned mail item.
+--------
| From MAILER-DAEMON@thyme Wed Aug 21 14:27:07 1985
| Received: from thyme.DAVIS.uucp by bluebell.DAVIS.uucp (4.24/3.14)
| id AA01211; Wed, 21 Aug 85 14:27:01 pdt
| Return-Path: <MAILER-DAEMON@thyme>
| Received: by thyme.DAVIS.uucp (4.24/3.14)
| id AA09674; Wed, 21 Aug 85 14:25:59 pdt
| Date: Wed, 21 Aug 85 14:25:59 pdt
| From: MAILER-DAEMON@thyme (Mail Delivery Subsystem)
| Subject: Returned mail: User unknown
| Message-Id: <8508212125.AA09674@thyme.DAVIS.uucp>
| To: root@thyme
|
| ----- Transcript of session follows -----
| 451 Who are you?: File table overflow
| >>> RCPT To:<ecs80sum008@clover>
| <<< 550 <ecs80sum008@clover>... User unknown
| 550 ecs80sum008... User unknown
|
| ----- Unsent message follows -----
| Received: by thyme.DAVIS.uucp (4.24/3.14)
| id AA09668; Wed, 21 Aug 85 14:25:59 pdt
| Date: Wed, 21 Aug 85 14:25:59 pdt
| From: root
| Message-Id: <8508212125.AA09668@thyme.DAVIS.uucp>
| To: ecs80sum008
|
| ----superfluous message text deleted to save space----
|
+--------
Following is the contents of the system's /usr/adm/messages file for
the time period in question. This is an unmodified block of text
from the file. I have included several lines, that are unrelated to
the problem, from just before the error occurred and from just after
it occurred.
+--------
| Aug 13 17:00
| ...
| Sun UNIX 4.2 Release 1.1 (THYME) #1: Tue Sep 25 12:28:40 PDT 1984
| Copyright (c) 1984 by Sun Microsystems, Inc.
| mem = 1920K (0x1e0000)
| avail mem = 1521664
| Ethernet address = 8:0:20:1:7:64
| xyc0 at mbio ee40 pri 2
| xy0 at xyc0 slave 0
| xy0: <Fujitsu-M2284/M2322 cyl 820 alt 3 hd 10 sec 32>
| sc0 at mbmem 80000 pri 2
| sd0 at sc0 slave 0
| st0 at sc0 slave 32
| ropc0 at obio ee0800 pri 1
| zs0 at obio eec800 pri 2
| zs1 at obio eec000 pri 2
| zs2 at mbmem 80800 pri 2
| zs3 at mbmem 81000 pri 2
| ec0 at mbmem e0000 pri 3
| bwtwo0 at obmem 700000 pri 3
| root on xy0
| using 70 buffers containing 143360 bytes of main memory
|
| Aug 21 14:00
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
|
| Aug 21 14:30
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
| inode: table is full
|
| Aug 21 15:00
| inode: table is full
| inode: table is full
|
| Aug 21 23:40
| daisy:
| trap type 8, pid 11760, pc = 32666, sr = 2000, context 0
| Bus Error Reg 4e18<PROTERR>
| access address 10b970 function code 5 rw 1 ifetch 0 dfetch 1 hibyte 0 bytex 0
| KERNEL MODE
| page map 0
| D0-D7 1 10b970 1 0 0 0 c6c c6c
| A0-A7 63842 3800 0 fffe50 10b970 63842 3f10 3ece
| Begin traceback...fp = 3f10, sp = 3ece
| Called from 133be, fp=3f30, args=636388 0 58000000 a
| Called from fde6, fp=3f48, args=a 3f80 200 200
| Called from 2ead4, fp=3f74, args=1 7f 98a00401 0
| Called from 4398, fp=fffe0c, args=10c c620 10965c 1
| End traceback...
| panic: Bus error
| syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done
|
| dumping to dev 301, offset 29760
| dump succeeded
| Rebooting Unix...
+--------
Can anyone shed any light on this for me? Thanks.
Michael Russell
...!ucbvax!ucdavis!russell
ucdavis!russell@berkeley.arpa
russell%ucdavis.uucp@berkeley.arpa
russell@ucd.csnetchris@umcp-cs.UUCP (Chris Torek) (08/23/85)
Nope. What happened was that you ran out of internal file table space, which made sendmail unable to figure out who was who, so it returned the mail to "root" as a last gasp dying effort to save the message from being black-holed. Try increasing "maxusers" in your configuration file. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jack@boring.UUCP (08/25/85)
[ It seems there is no such person as 'russell' @ ucb-vax. Funny..] Aha. That shows how the auto-reboot of 4.2 can bite you. The 'table overflow' didn't come from sendmail or mail, it came from the kernel. The kernel paniced (is that the right past tens of panic?), and did an auto-reboot. It seems that your kernel is configured to come up single user after a reboot. So, that explains why she was 'root' after the mail command, and why the second mail returned to root. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.