> Gary Mills wrote: > > I'm still looking for the place where it gets > blocked. > > I've attached a simple dtrace hack that might help. > Save it as > alrm.d", chmod +x, and run "./alrm.d -p > <pid-of-server>". (Or if > running from a command line, "./alrm.d -c > <command-line-and-args>".)
Thanks. That script helped to confirm that there was nothing in the FTP server code that either blocked or unblocked SIGALRM. I finally put a bit of code at the beginning of the main() function in ftpd.c to syslog a message when that signal was blocked. On a moderately busy anonymous FTP server, I found many instances when that was the case. Since the signal mask is inherited from the parent, it had to be the parent, inetd in this case, that was at fault. I confirmed this by inserting a wrapper between inetd and in.ftpd that did nothing but set SIGALRM to its default condition with sigset(). The FTP server never reported any more instances of a blocked signal after that. I've filed bug report 6913800 for this issue. I also tried to reproduce the problem under opensolaris, where I have source, but was never able to do so. I don't know what set of conditions would induce inetd to block that signal. Nevertheless, it does happen on an active anonymous FTP server. A fix for inetd is simply to set SIGALRM to its default condition before exec()ing the child process. A more complete fix would be just to clear the signal mask at that point. -- This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
