Tcpd was not broken...a truss -fp of inetd showed the tcpd was
execve()'ing into tcpd and then into the real daemon ok...
I left the client open for an extended period of time, and after about
seven to eight minutes, it returned and everything worked. I got a banner
back from the server (a 220 message on the ftp server) and the client
interacted perfectly. If I exit the client, and re-initiated, everything
worked fine. Until...
I kill -HUP inetd...
Then the first time that I connect with any client, ftp, ssh, or telnet, I
get the extended delay and everything works fine. My guess is that it is
having a hard time reintepreting /etc/inetd.conf...
So I did a truss -fp on inetd during a kill -HUP and it is attached here.
I've edited the truss to remove the /etc/shadow entries, but other than
that it is intact. Here is the sequence of events...
1. Truss -fp on inet pid
2. Every 5 seconds a timestamp is inserted in the file using date
3. kill -HUP pid
4. wait ten seconds
5. ftp connect from workstation
6. when the workstation connects I echoed "NOW" into the truss file
Thanks for your help. I'm toying with xinetd at the moment, but having
problems there also. I compiled it cleanly, but when I run it with
"/usr/sbin/xinetd -syslog local5" I get errors in /var/adm/messages for
ftp and ssh with your typical bind() error of "Address already in use"...
The address is NOT already in use, lsof -i reports that no process is
LISTEN'ing on these ports.
A clean reboot fixes the problem, until I kill -HUP inetd. If I kill
-KILL, or just kill -TERM, then when I invoke another instance of
/usr/sbin/inetd -s, I get the same problem. I have not tried launching
xinetd on boot, but plan to do so when I reboot the box this evening.
TIA,
Jesse Whyte
Security Analyst
State of Tennessee
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:16 CDT