Last night, we had a number of (but not all) alpha machines crash and reboot
multiple times, starting at around 21:00 EDT. This seemed to coincide with
the following type of message from xntpd on some of our SPARCstations:
Aug 28 05:06:27 deepthought xntpd[155]: too many recvbufs allocated (30)
It does not appear that all of the SPARC machines were hit either. The DEC
machines stopped crashing only after they ran out of space to save the crash
dumps, then they just sat in single-user mode, waiting for us to set
SAVECORE_FLAGS to M so that they could get to run state 3.
The alphas are all running the stock DEC xntp daemon, and are either running
V3.0 347 or V3.2 17 of DEC's OSF1 (does uname call it Digital Unix under 4.0?
;-). We have machines running both flavors of the OS, and they are on
different logical subnets (although they are on the same physical switched
subnet).
Our best guess at this point is that somebody was probing some of our machines
or trying some type of DOS (denial of service, not something from M$ :-)
attack, using the NTP port. I don't have any experience reading crash_data
files, but I found a stack trace on one system (the only one I've had the time
to check, so far):
_stack_trace[0]_begin:
> 0 boot(0x0, 0x0, 0xfffffc00004c0f60, 0x1, 0xffffffff89444a00) ["../../../../src/kernel/arch/alpha/machdep.c":1620, 0xfffffc00003c9ed0]
1 panic(s = 0xfffffc00004c0f60 = "psignal_indirect_alloc") ["../../../../src/kernel/bsd/subr_prf.c":752, 0xfffffc000038ba84]
2 psignal_indirect_alloc(0xffffffff894bb800, 0xffffffff00000000, 0xfffffc00003876a4, 0xffffffff894bb800, 0xfffffc0000000000) ["../../../../src/kernel/bsd/kern_sig.c":4506, 0xfffffc00003873a8]
3 pgsignal_indirect(0xffffffff894bb800, 0x17, 0x0, 0x10, 0xfffffc00002565bc) ["../../../../src/kernel/bsd/kern_sig.c":4616, 0xfffffc00003876a0]
4 gsignal(0x1, 0x17, 0x0, 0xffffffff895314a0, 0xfffffc00002efb0c) ["../../../../src/kernel/bsd/kern_sig.c":2154, 0xfffffc0000383a9c]
5 sowakeup(0xffffffff89531c60, 0xffffffff8b5038d0, 0xffffffff89444d00, 0xffffffff89444d00, 0xfffffc0000525c98) ["../../../../src/kernel/bsd/uipc_socket2.c":705, 0xfffffc0000255fb0]
6 udp_input(m = (nil), iphlen = 28) ["../../../../src/kernel/netinet/udp_usrreq.c":790, 0xfffffc00002efb24]
7 ipintr(0xfffffc00002e1f70, 0xfffffc00004acc90, 0xfffffc00005264e0, 0x6, 0xfffffc0000526d00) ["../../../../src/kernel/netinet/ip_input.c":698, 0xfffffc00002e2958]
8 netisr_thread() ["../../../../src/kernel/net/netisr.c":825, 0xfffffc00003c1e40]
_stack_trace[0]_end:
Below is a sample of what I've seen from uerf on some of the machines.
----- EVENT INFORMATION -----
EVENT CLASS ERROR EVENT
OS EVENT TYPE 302. PANIC
SEQUENCE NUMBER 1.
OPERATING SYSTEM DEC OSF/1
OCCURRED/LOGGED ON Wed Aug 27 21:07:09 1997
OCCURRED ON SYSTEM beth
SYSTEM ID xFFBC0004 CPU TYPE: DEC 3000
SYSTYPE x00000000
MESSAGE panic (cpu 0): psignal_indirect_alloc
So, does anybody have a clue as to what is going on here? Did somebody tickle
a bug in the kernel? Any ideas on how to prevent this in the future (short of
upgrading everything to 4.x)? Naturally, I will summarize any info I get back.
Thanks,
/Chris
Received on Thu Aug 28 1997 - 18:30:16 NZST