Bug 12607

Summary:	System crashes after boot, portmap endlessly forks with getport(ypbind), /proc and file tables filled up
Product:	Base System	Reporter:	conrad <conrad>
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.2-STABLE
Hardware:	Any
OS:	Any

Description conrad 1999-07-12 15:20:01 UTC

From time to time after boot, shortly after ypbind ist started
  nis_client_flags="-S foobar,dirac,avz109,avzw02"
The system crashes during the boot (you still get a shell ....,
rc just stops..)
Excerpt from syslog
...
Jul 12 12:13:00 merlin /kernel: changing root device to wd0s1a
Jul 12 12:13:00 merlin xntpd[123]: xntpd version=3.4e (beta multicast); Fri Jun 
25 21:56:36 CEST 1999 (1)
Jul 12 12:13:00 merlin xntpd[123]: tickadj = 5, tick = 10000, tvu_maxslew = 495
Jul 12 12:13:00 merlin xntpd[123]: precision = 6 usec
Jul 12 12:13:01 merlin xntpd[123]: using xntpd phase-lock loop
Jul 12 12:13:01 merlin xntpd[123]: system event 1 status c010
Jul 12 12:13:02 merlin /kernel: proc: table is full
Jul 12 12:13:03 merlin last message repeated 1300 times
Jul 12 12:13:03 merlin rpc.statd: Starting
Jul 12 12:13:03 merlin /kernel: proc: table is full
Jul 12 12:13:03 merlin last message repeated 29 times
Jul 12 12:13:03 merlin /kernel: file: table is full
Jul 12 12:13:03 merlin syslogd: /dev/console: Too many open files in system: Too
 many open files in system
Jul 12 12:13:03 merlin syslogd: /var/run/utmp: Too many open files in system

and so on, later in the syslog file:

Jul 12 12:13:07 merlin /kernel: proc: table is full
Jul 12 12:13:07 merlin last message repeated 43 times
Jul 12 12:13:07 merlin portmap[570]: connect from 127.0.0.1 to getport(ypbind)
Jul 12 12:13:07 merlin portmap[571]: connect from 127.0.0.1 to getport(ypbind)

last line serveral hundreds of time!!

Output from 'portmap -v -d' :
(hundresds of)      server: about to do a switch

Lastcomm says that the system is filled with portmappers...

excerpt from 'tcpdump -s 200 -vv host merlin':
(hundreds of time:)
12:13:07.109379 merlin.th.physik.uni-bonn.de.960 > dirac.th.physik.uni-bonn.de.9
93: udp 52 (ttl 64, id 11560)
12:13:07.109532 dirac.th.physik.uni-bonn.de.993 > merlin.th.physik.uni-bonn.de.9
60: udp 28 (ttl 64, id 38420)

(dirac (2.2.7-RELEASE) runs ypserv...)

I think its a ypbind problem (but I might be totally wrong...)
I have logs available: tcpdump syslog lastcomm

I've seen something like this on 2.2.7-RELEASE (dirac) some time ago,
but only once, so I can't supply any logs...

Fix: 

Unknown! (I don't see trough ypbind.c...)
How-To-Repeat: Just boot many many times :-)

Comment 1 Cyrille Lefevre 2000-05-09 06:38:15 UTC

Environment

FreeBSD gits 4.0-STABLE FreeBSD 4.0-STABLE #15: Tue May  9 00:32:14 CEST 2000     root@gits:/disk2/4.0-STABLE/src/sys/compile/CUSTOM  i386

Description

	I got the same problem while testing NIS services.
	I disabled all of them except that I forgot the
	nisdomainname=some.domain in the /etc/rc.conf file.
	after that, every time I try to start the portmapper
	(portmap -v) the machine hangs w/ proc table full.
	it's impossible to do a killall portmap or anything else,
	just reboot the soft way if possible or the hard way.

How-To-Repeat

	just put a nisdomainname=some.domain in /etc/rc.conf
	w/o enabling any NIS services. enable the portmapper.
	reboot your system and wait a few moment. if nothing
	happen, just try to use one of the rpc services (of
	course enabled in /etc/inetd.conf).

	it seems not possible to unset the NIS domainname
	once sets using domainname "" or the equivalent
	sysctl -w kern.domainname="". you need to reboot.

Fix
	don't set a NIS domainname w/o using NIS services.
--
home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr

Comment 2 conrad 2001-06-26 11:10:46 UTC

Hi,

I think we might close this PR.

The original problem never appeared again since we moved to >= 4.2.

For the followup I cannot speak.

ciao
	Jan

Comment 3 dwmalone freebsd_committer

2001-06-26 11:22:02 UTC

State Changed
From-To: open->closed

Problem hasn't been seen since 4.2.