Date: Tue, 22 Jun 1999 12:54:07 -0700 (PDT) From: mkc@graphics.cornell.edu To: freebsd-gnats-submit@freebsd.org Subject: bin/12349: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal Message-ID: <19990622195407.146E81552E@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 12349 >Category: bin >Synopsis: 3.2-R inetd doesn't re-read ALL configuration info at HUP signal >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 22 13:00:01 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Mitch Collinsworth >Release: 3.2-R >Organization: Cornell University >Environment: FreeBSD benge.graphics.cornell.edu 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08 GMT 1999 jkh@cathair:/usr/src/sys/compile/GENERIC i386 >Description: >How-To-Repeat: 1. vipw and append "+:::::::::" 2. edit /etc/group and append "+:" 3. start ypbind 4. edit /etc/inetd.conf and append: amanda dgram udp wait backup /usr/local/amanda/libexec/amandad amandad 5. send HUP signal to inetd result: "No such user backup, service ignored". >Fix: A workaround is to kill inetd completely and restart it. Not ideal when doing the above in a script on a live system that may be performing other tasks at the time. >Release-Note: >Audit-Trail: >Unformatted: >> >> I am putting an entry in inetd.conf with a non-root user field. >> >> This user is defined in NIS rather than in /etc/master.passwd. >> >> On 3.0-R and 3.1-R this works. On 3.2-R when I HUP inetd I get: >> >> "No such user 'user', service ignored". Putting a non-NIS entry >> >> into master.passwd for this user does get inetd to start the >> >> service. >> > >> >This begs the question, is NIS working? How did you activate NIS? >> >> Yes, NIS is working for everything except inetd in 3.2-R. > >Did you shutdown inetd totally then restart it? Apparently kill -HUP >inetd doesn't quite work correctly for certain configuration files. No I didn't. I've never heard of such a thing. However... It does in fact work! Now that we know this, it is conceivable 3.0-R and 3.1-R may have the same problem since I can't say for sure that I didn't reboot those systems sometime between configuration and testing. I would have to classify this as a bug. The HUP signal should cause all configuration info to be re-loaded. -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990622195407.146E81552E>