On the face of it I think this fix is inadequate, given that "maxsock + 1" is used in the select(). With no services, should select not have a 0 as the first argument, thus requiring maxsock to be -1 and not 0? All the problems fell out of that value.
-- Jim -----Original Message----- From: Denys Vlasenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2008 3:37 AM To: [EMAIL PROTECTED] Cc: Cathey, Jim; [email protected] Subject: Re: inetd bug > Cathey, Jim schrieb: >> We've been using BB, and found that when we had an /etc/inetd.conf >> file with only one service in it, said service being commented in >> and out as it was enabled/disabled by the system (along with a HUP >> to inetd), that the lone service could not re-enable. I tracked it >> down to a bug where the maxsock variable wasn't being used correctly. Can you explain where exactly that failed? Form what I can see, the only erroneous place is this one (fix is shown too): static void recalculate_maxsock(void) { int fd = 0; + maxsock = 0; while (fd <= prev_maxsock) { if (FD_ISSET(fd, &allsock)) maxsock = fd; Basically, if there are no services at all, maxsock was not updated and stayed -1, the rest of code was not expecting that can ever happen after recalculate_maxsock(). Am I right in my analysis or are there other places where code is wrong? IOW, does the above fix work for you? -- vda _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
