> Thanks. I see now that the bug is in the FTP
> server.
> It's not honouring its timeout on the data
> connection.
> I have this set to six hours, but some server
> children
> have been around for a week. I'll begin by looking
> at
> the source to be certain that I've set the timeout
> correctly, and that its actually interrupting the
> read().
It does seem to be a bug in the server. It's blocked in
a one-byte read on the data connection that's waiting
for the client to close it. It's this piece of code from
ftpd.c:
624 if (draconian_FILE != NULL)
625 shutdown(fd, 1);
626 if (draconian_FILE != NULL)
627 read(fd, &c, 1);
628 }
It does have an alarm() set around the read() but the
signal is blocked:
# psig 3520
3520: /usr/sbin/in.ftpd -a
HUP caught randomsig RESETHAND,NODEFER
...
PIPE ignored
ALRM blocked,caught 0x8056a6d RESETHAND,NODEFER
TERM default
The signal is never delivered. All I need to figure out
now is why it was blocked.
--
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
