From linux_4ever at yahoo.com Fri May 2 04:58:43 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Mail Test Message-ID: <20030502115843.71485.qmail@web9606.mail.yahoo.com> Hello, It would appear that the xinetd mail list has been down for a couple of weeks. A lot has happened while the list was down. Xinetd-2.3.11 was released, a bugtraq warning was issued, and hopefully people upgraded. Since you are getting this mail, it would appear we are open for discussion again. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From marya at st.jip.co.jp Mon May 5 19:16:36 2003 From: marya at st.jip.co.jp (Shinichi Maruyama) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd-2.3.11 -- FreeBSD 4.8-REL In-Reply-To: <20030502115843.71485.qmail@web9606.mail.yahoo.com> References: <20030502115843.71485.qmail@web9606.mail.yahoo.com> Message-ID: <20030506.111636.74753607.marya@st.jip.co.jp> linux_4ever> It would appear that the xinetd mail list has been down for linux_4ever> a couple of weeks. A lot has happened while the list was linux_4ever> down. Xinetd-2.3.11 was released, a bugtraq warning was linux_4ever> issued, and hopefully people upgraded. Since you are linux_4ever> getting this mail, it would appear we are open for linux_4ever> discussion again. In FreeBSD 4.8-RELEASE, xinetd-2.3.11 errors in make. gcc -O -pipe -g -O2 -I../libs/include -c signals.c signals.c: In function `mem_fault_handler': signals.c:357: `SEGV_MAPERR' undeclared (first use in this function) signals.c:357: (Each undeclared identifier is reported only once signals.c:357: for each function it appears in.) signals.c:360: `SEGV_ACCERR' undeclared (first use in this function) signals.c:358: warning: unreachable code at beginning of switch statement signals.c:371: `BUS_ADRALN' undeclared (first use in this function) signals.c:372: warning: unreachable code at beginning of switch statement FreeBSD 4.8-RELEASE has SVR4_SEGV_MAPERR, SVR4_SEGV_ACCERR, SVR4_BUS_ADRALN only in /usr/src/sys/svr4_siginfo.h for svr4 emulators. I made a patch not to use these values. -- MARUYAMA Shinichi -------------- next part -------------- --- signals.c.orig Sat Apr 26 02:39:01 2003 +++ signals.c Tue May 6 10:48:12 2003 @@ -354,23 +354,29 @@ switch (sig) { case SIGSEGV: switch (siginfo->si_code) { +#ifdef SEGV_MAPERR case SEGV_MAPERR: msg(LOG_CRIT, func, "address is not mapped for object"); break; +#endif +#ifdef SEGV_ACCERR case SEGV_ACCERR: msg(LOG_CRIT, func, "invalid permissions for mapped object"); break; +#endif default: - msg(LOG_CRIT, func, "unknown fault code"); + msg(LOG_CRIT, func, "unknown fault code %d",siginfo->si_code); } break; case SIGBUS: switch(siginfo->si_code) { +#ifdef BUS_ADRALN case BUS_ADRALN: msg(LOG_CRIT, func, "invalid address alignment"); break; +#endif #ifdef BUS_ADRERR case BUS_ADRERR: msg(LOG_CRIT, func, "nonexistent physical address"); @@ -382,7 +388,7 @@ break; #endif default: - msg(LOG_CRIT, func, "unknown fault code"); + msg(LOG_CRIT, func, "unknown fault code %d",siginfo->si_code); } break; } From linux_4ever at yahoo.com Tue May 6 04:12:38 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd-2.3.11 -- FreeBSD 4.8-REL In-Reply-To: <20030506.111636.74753607.marya@st.jip.co.jp> Message-ID: <20030506111238.43863.qmail@web9607.mail.yahoo.com> >I made a patch not to use these values. Looks good. I put it in cvs. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From asundell+xinetd at fas.harvard.edu Wed May 7 11:53:14 2003 From: asundell+xinetd at fas.harvard.edu (Alan Sundell) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] [PATCH] Make ident work on multihomed hosts Message-ID: <20030507185313.GA6309@is07.fas.harvard.edu> Hi, there. First, let me explain the problem: When doing an ident lookup, you need to bind() the socket of your outgoing connection to the same IP address as the incoming connection you're looking up. The ident server needs all four numbers describing the endpoints of the TCP connection in order to look it up in its local table. The ports it gets from the query; the IP addresses it gets by looking at the ident query connection itself (RFC 1413 sec 3). If the ident client connects from a different address than the one corresponding to the connection about which it's intending to query, the ident server won't find that TCP connection in its table, and might even find another connection belonging to another user and return that as a response. The attached minor patch (modifying ident.c) fixes ident lookups on multihomed hosts. I'm not sure if the patch fits your style, but it works for me, and should at least give you an idea what I'm talking about. --Alan Sundell -------------- next part -------------- diff -ur xinetd-2.3.11.orig/xinetd/ident.c xinetd-2.3.11/xinetd/ident.c --- xinetd-2.3.11.orig/xinetd/ident.c 2003-02-28 09:33:04.000000000 -0500 +++ xinetd-2.3.11/xinetd/ident.c 2003-04-19 18:36:09.000000000 -0400 @@ -60,7 +60,7 @@ { static char buf[ IBUFSIZE ] ; int cc ; - union xsockaddr sin_local, sin_remote, sin_contact; + union xsockaddr sin_local, sin_remote, sin_contact, sin_bind; volatile unsigned local_port; volatile unsigned remote_port; int sd ; @@ -109,6 +109,10 @@ remote_port = ntohs( sin_remote.sa_in.sin_port ) ; sin_contact.sa_in.sin_port = htons( IDENTITY_SERVICE_PORT ) ; } + /* set up struct for bind() */ + sin_bind = sin_local; + sin_bind.sa_in.sin_port = htons( 0 ) ; + sin_bind.sa_in6.sin6_port = htons( 0 ) ; /* * Create a socket and set the close-on-exec flag on the descriptor. @@ -128,6 +132,15 @@ return( IDR_ERROR ) ; } + /* + * bind() before connecting or ident will fail on multi-homed hosts + */ + if ( bind( sd, &sin_bind.sa, sizeof( sin_bind ) ) == -1 ) + { + msg( LOG_ERR, func, "socket bind: %m" ) ; + return( IDR_ERROR ) ; + } + if ( timeout ) { if ( sigsetjmp( env, 1 ) == 0 ) START_TIMER( timeout ) ; From linux_4ever at yahoo.com Thu May 8 08:10:12 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] [PATCH] Make ident work on multihomed hosts In-Reply-To: <20030507185313.GA6309@is07.fas.harvard.edu> Message-ID: <20030508151012.30776.qmail@web9601.mail.yahoo.com> >When doing an ident lookup, you need to bind() the socket >of your outgoing connection to the same IP address as the >incoming connection you're looking up. Yes, tcp_wrappers does rfc931 this way, too. I modified your patch slightly and submitted it to cvs this morning. The changes were: use a memcpy instead of depending on compiler to copy structure, move the port assignment into proper protocol branches, and close the socket when exiting function if error during bind. You should be able to check out xinetd via anonymous cvs and retest it. Thanks for pointing this out... -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From linux_4ever at yahoo.com Thu May 8 08:31:18 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] IPv6 redirect patch In-Reply-To: Message-ID: <20030508153118.83175.qmail@web9604.mail.yahoo.com> >I found one logical error in redirect.c. I my case I tried >to make IPv6->IPv4 proxy. I committed this patch to cvs today. When the patch was first submitted, I was in the middle of a big bug hunt. Xinetd is in better shape now, so the time is right for this correction. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From asundell+xinetd at fas.harvard.edu Thu May 8 09:25:24 2003 From: asundell+xinetd at fas.harvard.edu (Alan Sundell) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] [PATCH] Make ident work on multihomed hosts In-Reply-To: <20030508151012.30776.qmail@web9601.mail.yahoo.com> References: <20030507185313.GA6309@is07.fas.harvard.edu> <20030508151012.30776.qmail@web9601.mail.yahoo.com> Message-ID: <20030508162523.GA22760@is08.fas.harvard.edu> On Thu, May 08, 2003 at 08:10:12AM -0700, Steve G wrote: > The changes were: use a memcpy instead of depending on > compiler to copy structure, move the port assignment into > proper protocol branches, and close the socket when exiting > function if error during bind. Ugh. You're right; that was really sloppy :) > You should be able to check > out xinetd via anonymous cvs and retest it. I just checked out ident.c, but it works like a charm, now. Thanks! --Alan Sundell From xinetd at tlinx.org Fri May 9 14:06:03 2003 From: xinetd at tlinx.org (l walsh) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? Message-ID: <001501c3166e$cc918b90$1403a8c0@sc.tlinx.org> I'm a bit behind the times with SuSE 8.1, so this may already be fixed. I have xinetd v2.3.6-23. Seeing this in my log: econds May 9 04:26:22 ishtar xinetd[792]: Sending signal 9 to imaps server 2031 May 9 04:26:22 ishtar xinetd[792]: Server 2031 did not exit after SIGKILL May 9 04:26:22 ishtar xinetd[792]: Sending signal 9 to imaps server 5427 May 9 04:26:23 ishtar xinetd[792]: Server 5427 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 1472 May 9 04:26:23 ishtar xinetd[792]: Server 1472 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 8289 May 9 04:26:23 ishtar xinetd[792]: Server 8289 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 12292 May 9 04:26:23 ishtar xinetd[792]: Server 12292 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 2067 May 9 04:26:23 ishtar xinetd[792]: Server 2067 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 2180 May 9 04:26:23 ishtar xinetd[792]: Server 2180 did not exit after SIGKILL May 9 04:26:23 ishtar xinetd[792]: Sending signal 9 to imaps server 9917 May 9 04:26:23 ishtar xinetd[792]: Server 9917 did not exit after SIGKILL ---- It's been growing for a few days: seems it is trying to send signals to servers that no longer exist. I told it to do a self check, and I got: May 9 13:50:03 ishtar xinetd[792]: service imaps: actual running servers = 9, known running servers = 1 May 9 13:50:03 ishtar xinetd[792]: descriptor 3 set in socket mask but there is no service for it May 9 13:50:03 ishtar xinetd[792]: Consistency check detected 2 errors May 9 13:51:28 ishtar xinetd[792]: service imaps: actual running servers = 10, known running servers = 2 May 9 13:51:28 ishtar xinetd[792]: descriptor 3 set in socket mask but there is no service for it May 9 13:51:28 ishtar xinetd[792]: Consistency check detected 2 errors --- I guess the internal consistency check doesn't also include fixing the internal inconsistencies? I'm guessing this is fixed with some of the child wait code and such that was changed recently, but I thought I should log this anyway... -linda From linux_4ever at yahoo.com Fri May 9 19:28:23 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <001501c3166e$cc918b90$1403a8c0@sc.tlinx.org> Message-ID: <20030510022823.31441.qmail@web9605.mail.yahoo.com> >I'm a bit behind the times with SuSE 8.1, so this may >already be fixed. I have xinetd v2.3.6-23. 23 patches on top of 2.3.6...who knows what you are really running. ;) >I guess the internal consistency check doesn't also >include fixing the internal inconsistencies? No it doesn't. I personally don't think its worth the code or effort. If its inconsistent, restart it...this will take care of leaked resources as well. >I'm guessing this is fixed with some of the child wait >code and such that was changed recently, but I thought I >should log this anyway... I don't know if this is fixed. I will review the source code and see if I can think of how you might get into this situation. If this is easy to reproduce, you may want to build your own copy of xinetd-2.3.11 and temporarily use it instead of Suse's to see if its fixed. Also, if its easy to reproduce please send the recipe (simplified config + client side instructions) to make sure it gets fixed. BTW, is this server heavily used or lightly used? I'll report back what I find in the source code. Thanks, Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From xinetd at tlinx.org Sat May 10 08:54:25 2003 From: xinetd at tlinx.org (l walsh) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <20030510022823.31441.qmail@web9605.mail.yahoo.com> Message-ID: <000901c3170c$6e337ba0$1403a8c0@sc.tlinx.org> Grand total user count: 1. My normal ISP mail is downloaded via SSL IMAP from my ISP then remailed to me on my mail machine -- then any of my client machines (lately, only 1, but has been higher) access my email, presorted, on the mail server machine. I just ordered SuSE 8.2 (minor updates only, I'm told - I spend more on SuSE update software than I do MS OS's!). Since I've been running with this xinet for several months now, and this is the first I've noticed, either I changed something I didn't know would interact or it's a freak accident. So I wouldn't have a clue about how to go about repeating it -- and their's a fair chance it'll go away with the new release. As for reset on error detect - error detect could happen automatically periodically, and on detection, log it, fix what one can and go on. It's a 'reliability' thing -- building in 'auto-restart' even though it _shouldn't_ need it. All of MS's services have that option -- up to 3 different things to try when a service process fails in some way -- restart process, do nothing, restart computer. Yes -- it can cover up some bug (except for arcane messages in a log file), but when on a a "production system", covering up such a boo boo is preferable to requiring operator intervention. Thanks, -linda > -----Original Message----- > From: xinetd-admin@xinetd.org > [mailto:xinetd-admin@xinetd.org] On Behalf Of Steve G > Sent: Fri, May 09, 2003 7:28p > To: xinetd@xinetd.org > Subject: Re: [xinetd] Bug...already fixed? > > > >I'm a bit behind the times with SuSE 8.1, so this may > >already be fixed. I have xinetd v2.3.6-23. > > 23 patches on top of 2.3.6...who knows what you are really > running. ;) > > >I guess the internal consistency check doesn't also > >include fixing the internal inconsistencies? > > No it doesn't. I personally don't think its worth the code > or effort. If its inconsistent, restart it...this will take > care of leaked resources as well. > > >I'm guessing this is fixed with some of the child wait > >code and such that was changed recently, but I thought I > >should log this anyway... > > I don't know if this is fixed. I will review the source > code and see if I can think of how you might get into this > situation. If this is easy to reproduce, you may want to > build your own copy of xinetd-2.3.11 and temporarily use it > instead of Suse's to see if its fixed. Also, if its easy to > reproduce please send the recipe (simplified config + > client side instructions) to make sure it gets fixed. BTW, > is this server heavily used or lightly used? > > I'll report back what I find in the source code. > > Thanks, > Steve Grubb > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd > From linux_4ever at yahoo.com Sat May 10 10:51:32 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <000901c3170c$6e337ba0$1403a8c0@sc.tlinx.org> Message-ID: <20030510175132.29725.qmail@web9603.mail.yahoo.com> Hello, I reviewed the messages and code. I think your messages are coming from reconfigure. This is kicked off by sending xinetd SIGHUP. I found that the code was not entirely correct for certain services like tcpmux or services that may be suspended. I corrected the code and submitted it to cvs. I don't know if it fixes your problems since I couldn't duplicate it. xinetd 2.3.10 fixed some issues with the consistency check. I think it reported some things as problems that were expected conditions. The consistency check code may be correct now, but since its had bugs, would you really want self-repairing software to repair itself when there really wasn't a problem? If you don't trust xinetd or any daemon, I would schedule a restart early in the morning. xinetd has had so much code changed since 2.3.6, that its really hard to tell if the problem still exists. My recommendation would be to upgrade to the current code and see if that fixes it. Hopefully, Suse is shipping a recent xinetd. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From xinetd at tlinx.org Sat May 10 14:23:24 2003 From: xinetd at tlinx.org (l walsh) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <20030510175132.29725.qmail@web9603.mail.yahoo.com> Message-ID: <001301c3173a$654ec930$1403a8c0@sc.tlinx.org> > -----Original Message----- > From: xinetd-admin@xinetd.org > [mailto:xinetd-admin@xinetd.org] On Behalf Of Steve G > Sent: Sat, May 10, 2003 10:52a > To: xinetd@xinetd.org > Subject: RE: [xinetd] Bug...already fixed? > > > Hello, > > I reviewed the messages and code. I think your messages are > coming from reconfigure. This is kicked off by sending > xinetd SIGHUP. I found that the code was not entirely > correct for certain services like tcpmux or services that > may be suspended. I corrected the code and submitted it to > cvs. I don't know if it fixes your problems since I > couldn't duplicate it. --- Shouldn't have had any 'suspended' IMAP clients, but who knows. The machine has crashed a few times in the past 2 months or so, maybe some on-disk file didn't get updated. > xinetd 2.3.10 fixed some issues with the consistency check. > I think it reported some things as problems that were > expected conditions. The consistency check code may be > correct now, but since its had bugs, would you really want > self-repairing software to repair itself when there really > wasn't a problem? If you don't trust xinetd or any daemon, > I would schedule a restart early in the morning. --- I wouldn't be paying attention to it, is the problem. Last time I reviewed logs had to be more than 2 weeks ago. Everything has a possibility of having bugs. Hopefully, code that is designed to re-initialize state would be extra carefully written since its purpose is to return things to a normal state. Might not want to try to correct every problem automatically -- like fsck -- some problems it will handle automatically, others it doesn't know what to do and it requires manual intervention. Things like checking "I think there are 9 servers running", I look at /proc and only see 1 server. That one, a cleanup routine might be able to handle -- assumption -- somehow the parent missed the SIGCHILD. Some errors it could just exec itself and let it restart as though loaded fresh. Perhaps some errors it doesn't know what to do, so an option to send off a message for help (email root) would be good -- "help, I've fallen and I can't get up!" Measured responses to specific problems. Self-heal where you can -- my body does that -- small cut/bruise, autoheal. Human bodies do make mistakes 'auto-immune' disorders, but overall, automated responses to deal with injury are > xinetd has had so much code changed since 2.3.6, that its > really hard to tell if the problem still exists. My > recommendation would be to upgrade to the current code and > see if that fixes it. Hopefully, Suse is shipping a recent > xinetd. --- Absolutely 100% agree. Too old to be chasing it -- just thought I'd mention it as a datapoint so if someone else reports something similar.... People don't realize the value of bug reports even if they can't reproduce it since aggregate data can show trends. It's a way cool program, BTW, thanks much for creating it -- vast improvement over old inet. Now if we can just get RH to not put every bloomin' service in separate file. ARRRRGGGG...talk about maintenance headache. Sure it makes _some_ things easier, but overall, I like seeing all my services in 1 file. -linda From ma+xi at dt.e-technik.uni-dortmund.de Mon May 12 08:20:29 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <000901c3170c$6e337ba0$1403a8c0@sc.tlinx.org> (l. walsh's message of "Sat, 10 May 2003 08:54:25 -0700") References: <000901c3170c$6e337ba0$1403a8c0@sc.tlinx.org> Message-ID: "l walsh" writes: > Grand total user count: 1. > > My normal ISP mail is downloaded via SSL IMAP from my ISP then remailed > to me on my mail machine -- then any of my client machines (lately, > only 1, but has been higher) access my email, presorted, on the mail > server machine. > > I just ordered SuSE 8.2 (minor updates only, I'm told - I spend more > on SuSE update software than I do MS OS's!). I wouldn't update from 8.1 to 8.2 unless I had a dire need. Their public advertising of shipping a pre-release of gcc is reason enough to stay away from gcc. Red Hat gut burnt before with their "2.96" that never really existed, and now SuSE are following their tracks. It may work out, but I for one don't have time to waste figuring _that_ out. > Since I've been running with this xinet for several months now, and > this is the first I've noticed, either I changed something I didn't > know would interact or it's a freak accident. So I wouldn't have > a clue about how to go about repeating it -- and their's a fair > chance it'll go away with the new release. OTOH, installing the 8.1 source package, changing the spec file to point to 2.3.11 and dropping the patches (two edits per patch), dropping the 2.3.11 source tarball in, and rpm -bb /usr/src/packages/SPECS/xinetd.spec stands high chances of success. > As for reset on error detect - error detect could happen automatically > periodically, and on detection, log it, fix what one can and go on. > It's a 'reliability' thing -- building in 'auto-restart' even though > it _shouldn't_ need it. All of MS's services have that option -- up > to 3 different things to try when a service process fails in some way -- > restart process, do nothing, restart computer. Yes -- it can cover up > some bug (except for arcane messages in a log file), but when on a > a "production system", covering up such a boo boo is preferable to > requiring operator intervention. You can do the same with the default UNIX commands, so there. Use "reboot" for the hard way to recovery, or /etc/init.d/xinetd restart for the softer and usually cleaner way. But then again, just updating xinetd is going to suffice. If it turns out to be a SuSE issue, please don't forget to file a bug report to SuSE (through their technical feedback form) so they finally figure their xinetd is rotten. They usually don't respond too quickly, but eventually, they will. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Mon May 12 08:23:29 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <20030510175132.29725.qmail@web9603.mail.yahoo.com> (Steve G.'s message of "Sat, 10 May 2003 10:51:32 -0700 (PDT)") References: <20030510175132.29725.qmail@web9603.mail.yahoo.com> Message-ID: Steve G writes: > xinetd has had so much code changed since 2.3.6, that its > really hard to tell if the problem still exists. My > recommendation would be to upgrade to the current code and > see if that fixes it. Hopefully, Suse is shipping a recent > xinetd. That doesn't help those who don't feel like paying 49 EUR to upgrade, SuSE don't update existing packages unless they have critical (as in fails to start or is 100% unusable) or security relevant bugs. I told SuSE several times they should drop leafnode 1.9.19 and provide upgrade RPMs, they stuck with 1.9.19 although I pointed out to them that 1.9.19 could lose data. They just fixed some default permissions in their package. IOW: hope is misplaced when it comes to distributor reason. If you want distributors to update, file "critical" priority bug reports and point out that the newer version only had bug fixes. Then you'll have 20% chances they'll update... -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Mon May 12 08:38:07 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: SuSE 8.1 RPM of xinetd 2.3.11 (was: [xinetd] Bug...already fixed?) In-Reply-To: <001301c3173a$654ec930$1403a8c0@sc.tlinx.org> (l. walsh's message of "Sat, 10 May 2003 14:23:24 -0700") References: <001301c3173a$654ec930$1403a8c0@sc.tlinx.org> Message-ID: "l walsh" writes: > I wouldn't be paying attention to it, is the problem. Last > time I reviewed logs had to be more than 2 weeks ago. Everything > has a possibility of having bugs. Hopefully, code that is > designed to re-initialize state would be extra carefully written > since its purpose is to return things to a normal state. > Absolutely 100% agree. Too old to be chasing it -- just > thought I'd mention it as a datapoint so if someone else reports > something similar.... OK, just in case someone cares, I have SuSE 8.1 x86 RPMs of xinetd 2.3.11 (modeled after SuSE's original 2.3.6 package, but without any patches) for pentium-class machines, compiled with loadavg and libwrap options. Find it at http://mandree.home.pages.de/suse-8.1-i586.de/ Warning: anything you'll find there comes _without warranty_ and fitness for use, promised updates. It's just an effort to have more current packages when older one have had bugs that became known. Don't use for production before you've tested it thoroughly on a test machine. -- Matthias Andree From Antonin.Sprinzl at tuwien.ac.at Mon May 12 09:24:51 2003 From: Antonin.Sprinzl at tuwien.ac.at (Antonin Sprinzl) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Config question Message-ID: <20030512182451.A3582@sl.zid.tuwien.ac.at> Hi all 'roud, I'd like to redirect reqests to a specific port (let's say calls to port 21) BASED on IP's (domains). Is it doable somehow ? As far as I understand the config options I can redirest ALL traffic to another port (machine) but WITHOUT any discrimination. Antonin -- Money doesn't always bring happiness. People with ten million dollars are no happier than people with nine million dollars. -- Hobart Brown -- Antonin Sprinzl +43-1-58801-42033(tel) -42098(fax) See Homepage See Goodie Domain Service See Symph. Blasorchester From linux_4ever at yahoo.com Mon May 12 09:55:47 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Config question In-Reply-To: <20030512182451.A3582@sl.zid.tuwien.ac.at> Message-ID: <20030512165547.63196.qmail@web9608.mail.yahoo.com> >As far as I understand the config options I can >redirest ALL traffic to another port (machine) but >WITHOUT any discrimination. The inbound connection should go through the same tests as any other daemon. You should be able to use any and all connection rejection techniques: only_from, no_access, tcp_wrappers, per_source, max_load, etc. The outbound address doesn't change, though. All accepted connections must go to the same place. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From Antonin.Sprinzl at tuwien.ac.at Mon May 12 11:01:40 2003 From: Antonin.Sprinzl at tuwien.ac.at (Antonin Sprinzl) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Config question In-Reply-To: <20030512165547.63196.qmail@web9608.mail.yahoo.com>; from linux_4ever@yahoo.com on Mon, May 12, 2003 at 09:55:47AM -0700 References: <20030512182451.A3582@sl.zid.tuwien.ac.at> <20030512165547.63196.qmail@web9608.mail.yahoo.com> Message-ID: <20030512200139.A3929@sl.zid.tuwien.ac.at> On Mon, May 12, 2003 at 09:55:47AM -0700, Steve G wrote: > >As far as I understand the config options I can > >redirest ALL traffic to another port (machine) but > >WITHOUT any discrimination. > > The inbound connection should go through the same tests as > any other daemon. You should be able to use any and all > connection rejection techniques: only_from, no_access, > tcp_wrappers, per_source, max_load, etc. > > The outbound address doesn't change, though. All accepted > connections must go to the same place. > > -Steve Grubb Ohhh, I'm a d... ... I see right now I can define as much ftp services as I wish ... all defined differently :-) Tks Steve -- Antonin Sprinzl +43-1-58801-42033(tel) -42098(fax) See Homepage See Goodie Domain Service See Symph. Blasorchester From xinetd at tlinx.org Mon May 12 12:09:22 2003 From: xinetd at tlinx.org (l walsh) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: Message-ID: <000401c318b9$ff233660$1403a8c0@sc.tlinx.org> > I wouldn't update from 8.1 to 8.2 unless I had a dire need. > Their public > advertising of shipping a pre-release of gcc is reason enough to stay > away from gcc. Red Hat gut burnt before with their "2.96" that never > really existed, and now SuSE are following their tracks. It may work > out, but I for one don't have time to waste figuring _that_ out. --- Wasn't aware of this problem. SuSE used to be more quality minded -- as well as conservative. > OTOH, installing the 8.1 source package, changing the spec > file to point > to 2.3.11 and dropping the patches (two edits per patch), dropping the > 2.3.11 source tarball in, and rpm -bb > /usr/src/packages/SPECS/xinetd.spec stands high chances of success. --- If it was a critical problem that was taking down my system, or similar, I'd be tempted to take more selective measures, but when a Linux company issues an update, ya always gotta wonder -- will it be their last update? Mandrake's on the ropes, SuSE isn't swimming in black ink (profit) yet, RedHat has Microsoftesque momentum behind them. I doubt SuSE is in immediate danger, but I'm hoping for a few > > As for reset on error detect - error detect could happen > automatically > > periodically, and on detection, log it, fix what one can and go on. > > It's a 'reliability' thing -- building in 'auto-restart' even though > > it _shouldn't_ need it. All of MS's services have that option -- up > > to 3 different things to try when a service process fails > in some way -- > > restart process, do nothing, restart computer. Yes -- it > can cover up > > some bug (except for arcane messages in a log file), but when on a > > a "production system", covering up such a boo boo is preferable to > > requiring operator intervention. > > You can do the same with the default UNIX commands, so there. Use > "reboot" for the hard way to recovery, or /etc/init.d/xinetd > restart for > the softer and usually cleaner way. --- "You can do"....that's the point you are missing. The point was that with MS's service starting util, the computer does it for me -- ease of use; automation; I don't have to do anything - it does it automatically. It would be like xinetd detecting why a service exited (normal vs. segfault) and automatically restarting the service. MS refines the process a bit to give you up to 3 different actions to take on failure. 1) First and subsequent failures; 2) second and subsequent, and 3) third and subsequent. It's what action to take _automatically_ upon some unexpected failure. When I setup a system, I don't want to have to check it daily to see if it's working ok. I want it to be like the battery - alternator system on my car. When the battery gets low, it doesn't even tell me about it, it just automatically charges it via the alternator -- it's automatic -- only if the alternator can't charge, or if it is a "problem" it can't correct (I'm running out of gas), it turns on a "get driver attention" light. > But then again, just updating xinetd is going to suffice. If it turns > out to be a SuSE issue, please don't forget to file a bug > report to SuSE > (through their technical feedback form) so they finally figure their > xinetd is rotten. They usually don't respond too quickly, but > eventually, they will. --- If I can't isolate the problem to the xinet code what can I report? It could be a kernel problem not reporting something or a library problem, or one of many components. I so report bugs, but so often, I think it is a waste of time -- its' like the latest Passport Microsoft bug -- someone reported it to them for weeks and MS just ignored them. Finally they leaked it publically, and it turns out MS's central security feature had a very basic flaw. Until software companies are liable for faulty products, there is little incentive to fix problems --- in fact, financially, companies that waste time fixing bugs rather than focusing on features won't attract as many customers and are less likely to stay in business. The only thing the capitalistic system gives us is software at cheapest cost with minimum quality that the consumer will put up with. Even with money not directly at stake, as in the Free Software movement, quality is affected, since there is constant pressure from the "non-free" commercial products to improve features -- so constant pressure from MS to add features -- just to remain compatible, so a Free software developer has a choice, spend little free time on quality but it's yesturday's standards and technology, or spend time on "keeping up with the Jones" (or the "Gates" in this situation). :-0 -linda From linux_4ever at yahoo.com Mon May 12 13:17:04 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Config question In-Reply-To: <20030512200139.A3929@sl.zid.tuwien.ac.at> Message-ID: <20030512201704.95819.qmail@web9608.mail.yahoo.com> >I can define as much ftp services as I wish Yes, as long as they are bound to different IP addresses. You will also need to use the "id" option to give each ftp service a different id. Then each one can have a different filter to reject the connection from outsides and then connect to the appropriate machine. Ftp may have problems being forwarded since it requires 2 ports. I've seen this discussed at the stunnel mail list occassionally. -Steve __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Mon May 12 18:13:51 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <000401c318b9$ff233660$1403a8c0@sc.tlinx.org> (l. walsh's message of "Mon, 12 May 2003 12:09:22 -0700") References: <000401c318b9$ff233660$1403a8c0@sc.tlinx.org> Message-ID: "l walsh" writes: >> I wouldn't update from 8.1 to 8.2 unless I had a dire need. >> Their public >> advertising of shipping a pre-release of gcc is reason enough to stay >> away from gcc. Red Hat gut burnt before with their "2.96" that never >> really existed, and now SuSE are following their tracks. It may work >> out, but I for one don't have time to waste figuring _that_ out. > --- > Wasn't aware of this problem. SuSE used to be more quality > minded -- as well as conservative. They may succeed with their new GCC -- but they may be the first to find the code bugs that older GCC versions didn't reveal, and that would give them bad press nonetheless. And bad press isn't exactly what distros need. > "You can do"....that's the point you are missing. The point > was that with MS's service starting util, the computer does it for > me -- ease of use; automation; I don't have > to do anything - it does it automatically. It would be like xinetd > detecting why a service exited (normal vs. segfault) and automatically > restarting the service. MS refines the process a bit to give you > up to 3 different actions to take on failure. 1) First and subsequent > failures; 2) second and subsequent, and 3) third and subsequent. Well, can you "rsync" the configuration with MS? No? That's why one MS box makes dozens of Unix boxes, effort-wise. Services aren't supposed to fail in the first place. xinetd will restart any daemon that exited when the client requests it (once the daemon died, the client will have to reconnect anyhow, MS can't change that without breaking TCP), so the only issues you might see would be implementation bugs in xinetd. There used to be many, but the situation has improved. > It's what action to take _automatically_ upon some unexpected > failure. When I setup a system, I don't want to have to check it > daily to see if it's working ok. That's a moot point. If someone is into the security business, then auditing and checking and all that is essential. > I want it to be like the battery - alternator system on my car. When > the battery gets low, it doesn't even tell me about it, it just > automatically charges it via the alternator -- it's automatic -- only > if the alternator can't charge, or if it is a "problem" it can't > correct (I'm running out of gas), it turns on a "get driver attention" > light. Yup, and you're lost when the battery is all worn out after some years ;-) Of course, broken checks are worse than no checks at all, but if that's a problem with Mandrake's obsolete xinetd versions, they might want to be told. Same with SuSE. They used to be a lot more responsive, and I don't like anyone's "fixed in the next $$$ release", but MS isn't better here. > If I can't isolate the problem to the xinet code what can I > report? It could be a kernel problem not reporting something or > a library problem, or one of many components. Report the symptoms if they show up again. > I so report bugs, but so often, I think it is a waste of time -- > its' like the latest Passport Microsoft bug -- someone reported it to > them for weeks and MS just ignored them. Finally they leaked it > publically, and it turns out MS's central security feature had a > very basic flaw. Full disclosure lists are at your service if security bugs don't get fixed on short notice. I wouldn't wait all too long for serious issues. If the vendor doesn't get back to me in 5 days for important issues -> mail to bugtraq, let them stew in their own grease. > Even with money not directly at stake, as in the Free Software > movement, quality is affected, since there is constant pressure from > the "non-free" commercial products to improve features -- so constant > pressure from MS to add features -- just to remain compatible, so a > Free software developer has a choice, spend little free time on > quality but it's yesturday's standards and technology, or spend time > on "keeping up with the Jones" (or the "Gates" in this situation). Just keeping up is a losing game. Microsoft didn't invent SSH, the GUI or IMAP... If you have unique features that somebody else doesn't have, then you can take the lead. Back to xinetd, it is one of the popular replacements for inetd, but there are others; the combination of daemontools and tcpserver is reliable and without nasty surprises after you've got your service running. It doesn't serve UDP, TCPMUX, RPC and takes more effort to set up a service though. -- Matthias Andree From linux_4ever at yahoo.com Mon May 12 19:42:27 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: Message-ID: <20030513024227.27692.qmail@web9601.mail.yahoo.com> >>If I can't isolate the problem to the xinet code what can >>I report? It could be a kernel problem not reporting >>something or a library problem, or one of many components. Linda, the problem is obviously xinetd 2.3.6 + 23 patches. The messages came from reconfiguration code. You do not need to look any further. The question I think is pertinent is why is reconfigure being called? Did you send SIGHUP to xinetd? If you did, you should look in your logs and not assume everything went OK unless you enjoy surprises. >Report the symptoms if they show up again. Right. But please upgrade to something recent. There's thousands of lines of code that's changed. Xinetd has undergone a rapid maturity process over the last year. I really think its safe to say that its just now stabilizing. Then there's no way that I can even begin to guess what the 23 patches have in it. If you want to run vanilla xinetd as Matthias provided the srpms, I might be able to help you if you still have problems. When a vendor adds 23 patches... you need to talk with them. >>I report bugs, but so often, I think it is a waste of time >Full disclosure lists are at your service if security >bugs don't get fixed on short notice. Right. I second the motion. You remember the apache 2.0.45 release a couple weeks ago, I found the cgi descriptor leak back in August of last year & reported it. In October I reported it again. In Novemeber I got an e-mail from apache saying yes we see it. I sent notice to bugtraq & cert. Bugtraq did not publish it, cert did not acknowlege the problem. In December, I wrote a story for slashdot, they didn't post it. Then I wrote an article for linuxsecurity.com in January. They didn't publish it, but they wrote an article about the tool I used to find the problem. In February, I decided times up & posted it to vuln-dev. Then I got some action, however, I nearly had to write the exploit code to get action. When apache finally released the correction, they gave credit to 2 other people. Cert contacted me 3 weeks ago and said they were just getting to my report. So much for open source... In any event, forget self repairing software, it aint gonna happen. If you can't trust the main code, why would you trust the fixup code? You should also be aware that most people want a lean inetd. Xinetd right now occupies more memory than it should. Inetd was invented to save memory. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From xinetd at tlinx.org Mon May 12 23:51:55 2003 From: xinetd at tlinx.org (l walsh) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <20030513024227.27692.qmail@web9601.mail.yahoo.com> Message-ID: <000301c3191c$2414fdc0$1403a8c0@sc.tlinx.org> > -----Original Message----- > From: Steve G > Linda, the problem is obviously xinetd 2.3.6 + 23 patches. --- I don't know if the -23 means that many patches -- I think it means that many 'upgrades' to the collection of patches have been made -- I would think, theoretically, it could be all 1 patch with 23 revisions -- but I don't know how SuSE does their versioning. Wait a sec....I can look.... ok, we have the tar, they added an FAQ, a README.SuSE, a sample config some updates to the ia64 and man pages and 1 code diff file that says it removes an old variable (21 lines total in patch). > The messages came from reconfiguration code. You do not > need to look any further. The question I think is pertinent > is why is reconfigure being called? --- Just guessing, but I'd since the messages happened at around 2-3 in the morning, at the same time, I thought it was some process doing housecleaning -- like maybe a log-rotate daemon that restarted xinetd so it'd use the new log....but that's just a guess w/o looking. Because the log-rotate daemon wakes up around 2 every morning and spins various process's logs? Not very interesting. Did you send SIGHUP to > xinetd? If you did, you should look in your logs and not > assume everything went OK unless you enjoy surprises. --- Yeah, I'm going to wake up every morning and inspect my logs on my various computers to see that everything is proper -- just like I go and run a diagnostic on my car engine every morning before I drive anywhere. Computers are not the object. They are the means. They are the means to do something else (on a social level, anyway). My ex couldn't care less about the technology -- they just wanted to watch a movie or shop. For them the computer is like a car. Yeah, it needs maintenance once in a while, but if I have to run out and see if it is stolen every couple of hours. I lock my doors and forget them. I don't obsess about security. Well, ok, maybe a little....but only at times! I want to be able to lock my door and not have to worry unless the keys get stolen or the door is falling apart or something. > > >Report the symptoms if they show up again. > > Right. But please upgrade to something recent. There's > thousands of lines of code that's changed. Xinetd has > undergone a rapid maturity process over the last year. I > really think its safe to say that its just now stabilizing. > Then there's no way that I can even begin to guess what the > 23 patches have in it. If you want to run vanilla xinetd as > Matthias provided the srpms, I might be able to help you if > you still have problems. When a vendor adds 23 patches... > you need to talk with them. -- Looked like one patch to me, might have been 23 revisions of the xinet.conf file for their setup as they changed their startup system to use xinetd instead of inetd by default and as their dir struct changed to match the latest rev of the linux file system standard. > >>I report bugs, but so often, I think it is a waste of > time > > >Full disclosure lists are at your service if security > >bugs don't get fixed on short notice. > > Right. I second the motion. You remember the apache 2.0.45 > release a couple weeks ago, I found the cgi descriptor leak > back in August of last year & reported it. --- Unfortunately the bugs I find are more often not direct security threats...just annoyances or roadblocks to getting things done. > In any event, forget self repairing software, it aint gonna > happen. --- If you can't conceive of an organism healing itself it might not ever come into existance -- but others might conceive of such. > If you can't trust the main code, why would you > trust the fixup code? --- In this case, the main code is 'xinetd' -- an internet uber process that manages requests on ports and service programs. If my 'sshd' would die, I'd really like it if some uber process was watching and had been directed to restart it especially if I'm working remotely and the error was cause by a gamma ray hitting more non-ECC ram. You should also be aware that most > people want a lean inetd. Xinetd right now occupies more > memory than it should. Inetd was invented to save memory. --- That may have been the original purpose, but now other issues are more important than memory. Memory is cheap, security is expensive. Reliability is expensive. For some such processes the difference between 99.9% and 99.999% reliability is measured in billions. If memory is a concern on a server when memory is about $30-40 for 256M that's another concern, but memory using features could be kept in a separate run-time loadable library -- so normally, if those features are not used, the memory isn't used or mapped. Only when you map in the library does the memory get used. You could start off with a pretty small core program and only load features you need. Doesn't the Xserver operate that way? Self-healing systems are self-healing because they have many redundancies in them. No part is expected to be perfect. You could use the argument: if skin can be broken so easily why would you trust self-fixing skin to heal a wound? No? Xinet has program malfunction protections in it -- process spawn limits, connections/second limit. Aren't they a way to mitigate a potentially broken program? -linda From linux_4ever at yahoo.com Tue May 13 03:28:20 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <000301c3191c$2414fdc0$1403a8c0@sc.tlinx.org> Message-ID: <20030513102820.24962.qmail@web9603.mail.yahoo.com> Hello, I cannot buy the log rotate doing a SIGHUP. If it does, thats a bug. It should do a TERM & a start. SIGHUP means go re-read the config without pausing. I feel pretty confident that if you upgrade your rpm, your problems will be fixed. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Tue May 13 07:21:08 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Bug...already fixed? In-Reply-To: <20030513102820.24962.qmail@web9603.mail.yahoo.com> (Steve G.'s message of "Tue, 13 May 2003 03:28:20 -0700 (PDT)") References: <20030513102820.24962.qmail@web9603.mail.yahoo.com> Message-ID: Steve G writes: > Hello, > > I cannot buy the log rotate doing a SIGHUP. If it does, > thats a bug. It should do a TERM & a start. SIGHUP means go > re-read the config without pausing. Well, there are several log rotation packages out there, and some support sending SIGHUP or whatever, but on SuSE 8.1, I can't seem to find hints that xinetd gets regularly prodded to let go of its files. (The logrotate stuff does SIGHUP syslogd, but that's safe AFAIK.) -- Matthias Andree From djs at uci.edu Wed May 14 08:58:09 2003 From: djs at uci.edu (Donald Saltarelli) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] record option In-Reply-To: <20030513024227.27692.qmail@web9601.mail.yahoo.com> References: <20030513024227.27692.qmail@web9601.mail.yahoo.com> Message-ID: <1052927888.28001.121.camel@comput6.eng.uci.edu> Steve- just want to let you know that the RedHat package just released may fail to start on some people's machines because they have the 'record' logging option in their config. -- Donald Saltarelli Computing Support The Henry Samueli School of Engineering djs@uci.edu From linux_4ever at yahoo.com Wed May 14 09:40:24 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] record option In-Reply-To: <1052927888.28001.121.camel@comput6.eng.uci.edu> Message-ID: <20030514164024.59770.qmail@web9604.mail.yahoo.com> Hello, I did mention that to the Red Hat maintainer. I also looked at recent files in /etc/xinetd.d and saw that RECORD was not being used anymore. The other curious part of it is that there never was any code in xinetd that performed RECORD. Xinetd also has raw & seqpackets for socket type. There is absolutely no code behind these options too. Hopefully, no one is using these even though the man page says you can. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From ldv at altlinux.org Wed May 14 09:52:37 2003 From: ldv at altlinux.org (Dmitry V. Levin) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] record option In-Reply-To: <20030514164024.59770.qmail@web9604.mail.yahoo.com> References: <1052927888.28001.121.camel@comput6.eng.uci.edu> <20030514164024.59770.qmail@web9604.mail.yahoo.com> Message-ID: <20030514165237.GA18778@basalt.office.altlinux.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.xinetd.org/pipermail/xinetd/attachments/20030514/6443a96d/attachment.bin From ma+xi at dt.e-technik.uni-dortmund.de Wed May 14 16:41:10 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] record option In-Reply-To: <1052927888.28001.121.camel@comput6.eng.uci.edu> (Donald Saltarelli's message of "14 May 2003 08:58:09 -0700") References: <20030513024227.27692.qmail@web9601.mail.yahoo.com> <1052927888.28001.121.camel@comput6.eng.uci.edu> Message-ID: Donald Saltarelli writes: > Steve- just want to let you know that the RedHat package just released > may fail to start on some people's machines because they have the > 'record' logging option in their config. Well, I figured that the same was true for the default configuration that SuSE ship, and so the default configuration of the xinetd 2.3.11 RPM I provided fell over. My xinetd-2.3.11-2 RPM fixes that (at install-time it also removes the extra RECORD option in /etc/xinetd.conf), the RPM is meant for SuSE 8.1 on Pentium-compatible machines; download from http://mandree.home.pages.de/suse-8.1-i586.de/ Also, the xinetd-2.3.11-2 RPM strips the exectuables (from debugging symbols) and is therefore much smaller now (only 134 kB as opposed to 474 kB). -- Matthias Andree From fenlason at redhat.com Fri May 16 15:15:14 2003 From: fenlason at redhat.com (Jay Fenlason) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Patch for bug in redirect Message-ID: <20030516221514.GB26611@redhat.com> This patch appears to fix http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60049 which is a failure when a redirected service is running when the state of another service changes. (My automated test script uses "daytime" with a "cps = 2 10" option.) Can someone who knows the internals of xinetd better than I do confirm that this actually closes all the descriptors that must be closed in the child? -- JF Index: redirect.c =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/redirect.c,v retrieving revision 1.3 diff -u -r1.3 redirect.c --- redirect.c 8 May 2003 15:21:49 -0000 1.3 +++ redirect.c 16 May 2003 22:10:18 -0000 @@ -33,6 +33,8 @@ #include "log.h" #include "sconf.h" #include "msg.h" +#include "state.h" +#include "main.h" #define NET_BUFFER 1500 @@ -63,6 +65,8 @@ struct timeval *timep = NULL; const char *func = "redir_handler"; union xsockaddr serveraddr ; + psi_h iter ; + struct service *osp ; if( signal(SIGPIPE, redir_sigpipe) == SIG_ERR ) { msg(LOG_ERR, func, "unable to setup signal handler"); @@ -125,6 +129,18 @@ FD_ZERO(&msfd); FD_SET(RedirDescrip, &msfd); FD_SET(RedirServerFd, &msfd); + + /* Have to close all other descriptors here */ + iter = psi_create( SERVICES( ps ) ) ; + if ( iter == NULL ) + { + out_of_memory( func ) ; + } + for ( osp = SP( psi_start( iter ) ) ; osp ; osp = SP( psi_next( iter ) ) ) + { + (void) Sclose( SVC_FD( osp ) ) ; + } + psi_destroy( iter ) ; while(1) { memcpy(&rdfd, &msfd, sizeof(rdfd)); From linux_4ever at yahoo.com Fri May 16 17:29:09 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Patch for bug in redirect In-Reply-To: <20030516221514.GB26611@redhat.com> Message-ID: <20030517002909.97761.qmail@web9606.mail.yahoo.com> Hello Jay, I think the proper fix may be a little more extensive and/or placed in a more central location. I think I see what's happening. I haven't duplicated it, but understand the gist of the problem. I'll try to post a full patch tomorrow to the mail list. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From linux_4ever at yahoo.com Sun May 18 05:27:01 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Patch for bug in redirect In-Reply-To: <20030516221514.GB26611@redhat.com> Message-ID: <20030518122701.28336.qmail@web9602.mail.yahoo.com> Hello, I've had time to lookover Jay's patch. Its correct in its actions AFAICT. I changed it somewhat, though. I moved it to service.c, gave it a name of close_all_svc_descriptors and sprinkled calls from serveral places. It turns out that the patch only solved 1 of several problems. All services that fork, but do not exec, need to close the listening file descriptor so that any reconfigs do not error trying to bind to their address. These services include: redirected, builtins, & tcpmux. Services that fork and exec close the listening descriptors since the close on exec flag is set. I committed the revised patch to cvs, so everyone can try it. Thanks Jay for pointing this out. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From themattlyon at hotmail.com Tue May 20 21:35:53 2003 From: themattlyon at hotmail.com (Matt Lyon) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init Message-ID: This is a bit of a newb question so please excuse me. I have installed xinetd. My question lies in how do I get it to run at start up. I would like to have it start with init but I do not know how to write a start up script for it. Did I just miss it in the source, is this not the way to do it, or do I just need the proper script for init? Also, on my system it is using init to start up apache. From what I have read I should be doing this with xinetd along with all other services that use the web. On this distro init starts up all the services that come with this package and they didn't use inet.d at all. Should I use xinetd for them all or pick and choose. Thanks Matt _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From dp at co.ru Wed May 21 04:49:35 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] upgrade 2.3.0 -> 2.3.11 and /etc/sevices problem Message-ID: <3ECB67CF.8D5E651B@co.ru> Hi! There is next problem - when I try to upgrade my 2.3.0 to 2.3.11 I get many errors: 03/5/21@15:23:51: ERROR: 22094 {check_entry} service/protocol combination not in /etc/services: s0001/tcp 03/5/21@15:23:51: ERROR: 22094 {check_entry} service/protocol combination not in /etc/services: s0002/tcp ............ 03/5/21@15:23:51: ERROR: 22094 {check_entry} service/protocol combination not in /etc/services: s9999/tcp When I check diffences for check_entry() between 2.3.0 & 2.3.11 I noticed, that line: if( SC_SPECIFIED( scp, A_PROTOCOL) && SC_SPECIFIED( scp, A_PORT ) ) return(OK); disappeared from 2.3.11 ! So, I must add tons of my own non-standart services into /etc/services file. But it is very uncomfortable. Is it possible return old functionality ?(if proto & port defined for servece - does not check /etc/services). With respect. -- Dmitry Perfilyev From linux_4ever at yahoo.com Wed May 21 05:28:59 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] upgrade 2.3.0 -> 2.3.11 and /etc/sevices problem In-Reply-To: <3ECB67CF.8D5E651B@co.ru> Message-ID: <20030521122859.79427.qmail@web9604.mail.yahoo.com> Hello, The parser and xinetd configuration was somewhat sloppy back in the 2.3.0 days and certain combinations of things would cause xinetd to core dump. You can get the old functionality simply by adding: type = UNLISTED to the service's config settings. This has been in the man pages for a very long time, but it wasn't enforced. Hope this helps, -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From linux_4ever at yahoo.com Wed May 21 06:01:24 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init In-Reply-To: Message-ID: <20030521130124.78529.qmail@web9606.mail.yahoo.com> >My question lies in how do I get it to run at start up. >I would like to have it start with init but I do not know how >to write a start up script for it. If your init system uses chkconfig, you can copy contrib/xinetd to the proper directory (/etc/rc.d/init.d ?) and run: chkconfig --add xinetd If bad come to worse, you can always just add: xinetd -pidfile /var/run/xinetd.pid -stayalive to the rc.local file (don't forget to adjust the pidfile location for your directory layout). That's not the best way, but it would work. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From dp at co.ru Wed May 21 06:15:10 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] upgrade 2.3.0 -> 2.3.11 and /etc/sevices problem References: <20030521122859.79427.qmail@web9604.mail.yahoo.com> Message-ID: <3ECB7BDE.2A1FFE0A@co.ru> RTFM, in short :) Thanks. -- Dmitry Perfilyev JSC Combellga www.co.ru From themattlyon at hotmail.com Wed May 21 06:59:17 2003 From: themattlyon at hotmail.com (Matt Lyon) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Re: xinetd and init Message-ID: Thanks for the reply. It never occurred to me to look there for the init script. Thanks for the help. Matt _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From themattlyon at hotmail.com Wed May 21 08:01:50 2003 From: themattlyon at hotmail.com (Matt Lyon) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init Message-ID: Ok, one last problem. I have it all working except for ntsysv and chkonfig. When I typed in "ntsysv" after start up it gave an error - failed to open xinet.d: No such file or directory. Then when running "chkconfig --list" it posted the same error but was preceeded by - xinetd base services. I assume that it is looking for the file that was supposed to be converted by the perl script. I never ran it cause I didn't have any inet.d processes. One more note. When installing xinetd installed to /usr/local/sbin. I had to copy xinetd to /usr/sbin so that the init script would work. Other than that I haven't done anything different that I can remember while trying to get this to work. If I create a xinet.d file and leave it bland would that satisfy the request or does it need something in it to work properly. thanks matt _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From linux_4ever at yahoo.com Wed May 21 08:33:45 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init In-Reply-To: Message-ID: <20030521153345.5550.qmail@web9606.mail.yahoo.com> >I have it all working except for ntsysv and chkonfig. When >I typed in "ntsysv" after start up it gave an error - >failed to open xinet.d: No such file or directory. /etc/xinetd.d is a directory. Some people put each service in its own file in that directory. xinetd.conf usually includes that directory. >I assume that it is looking for the file that was >supposed to be converted by the perl script. No. >One more note. When installing xinetd installed to /usr/local/sbin. I had to copy xinetd to /usr/sbin so that >the init script would work. I always build it like: ./configure --sbindir=/usr/sbin --mandir=/usr/share/man --with-libwrap I also use it on a RH machine and that's where they put those. The init script is tuned for that layout, but you can edit the init script to your liking. >If I create a xinet.d file and leave it bland would that >satisfy the request or does it need something in it to >work properly. mkdir /etc/xinetd.d chown root /etc/xinetd.d chgrp root /etc/xinetd.d chmod 0700 /etc/xinetd.d Is all you need to do. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Wed May 21 14:10:38 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init In-Reply-To: <20030521153345.5550.qmail@web9606.mail.yahoo.com> (Steve G.'s message of "Wed, 21 May 2003 08:33:45 -0700 (PDT)") References: <20030521153345.5550.qmail@web9606.mail.yahoo.com> Message-ID: Steve G writes: > I always build it like: > > ./configure --sbindir=/usr/sbin --mandir=/usr/share/man > --with-libwrap SuSE also compile --with-loadavg for their SuSE Linux products. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Wed May 21 14:26:39 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] xinetd and init In-Reply-To: <20030521130124.78529.qmail@web9606.mail.yahoo.com> (Steve G.'s message of "Wed, 21 May 2003 06:01:24 -0700 (PDT)") References: <20030521130124.78529.qmail@web9606.mail.yahoo.com> Message-ID: Steve G writes: >>My question lies in how do I get it to run at start up. >>I would like to have it start with init but I do not know > how >to write a start up script for it. > > If your init system uses chkconfig, you can copy > contrib/xinetd to the proper directory (/etc/rc.d/init.d ?) > and run: There are valid reasons for the wish to run xinetd from inittab, most importantly, the "respawn" mode. However, this isn't currently supported, xinetd insists on detaching itself from its master process, so init would just disable the process after it looped. Note, you won't be able to abort xinetd running in your shell (if testing) with Ctrl-C, you can instead type Ctrl-\ (to send SIGQUIT) in most terminals. I am attaching a minimal patch below to add a "-dontfork" option, this enables xinetd to be run from init or daemontools . It is lightly tested and works for me. Example line for a SysV-ish /etc/inittab: xi:345:respawn:/usr/local/sbin/xinetd -stayalive -dontfork Example "run" script for a supervise directory for daemontools: #! /bin/sh exec /usr/local/sbin/xinetd -stayalive -dontfork Here's the patch (against current CVS): Index: xinetd/init.c =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/init.c,v retrieving revision 1.3 diff -u -r1.3 init.c --- xinetd/init.c 8 May 2003 14:52:24 -0000 1.3 +++ xinetd/init.c 21 May 2003 21:06:26 -0000 @@ -334,7 +334,7 @@ init_common( argc, argv ) ; - if ( ! debug.on ) + if ( ! debug.on && !dont_fork ) become_daemon() ; init_rw_state() ; Index: xinetd/options.c =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/options.c,v retrieving revision 1.2 diff -u -r1.2 options.c --- xinetd/options.c 13 May 2003 19:33:21 -0000 1.2 +++ xinetd/options.c 21 May 2003 21:06:27 -0000 @@ -31,6 +31,7 @@ int stayalive_option=0; char *program_name ; int inetd_compat = 0 ; +int dont_fork = 0; static void usage(void); @@ -83,6 +84,9 @@ } else if ( strcmp( &argv[ arg ][ 1 ], "stayalive" )==0) { stayalive_option = 1; + } + else if ( strcmp( &argv[ arg ][ 1 ], "dontfork" )==0) { + dont_fork = 1; } else if ( strcmp( &argv[ arg ][ 1 ], "logprocs" ) == 0 ) { Index: xinetd/options.h =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/options.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 options.h --- xinetd/options.h 19 Feb 2003 17:29:28 -0000 1.1.1.1 +++ xinetd/options.h 21 May 2003 21:06:27 -0000 @@ -18,6 +18,7 @@ extern unsigned logprocs_option_arg; extern int stayalive_option; extern char *program_name; +extern int dont_fork; int opt_recognize(int argc,char *argv[]); Index: xinetd/xinetd.man =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/xinetd.man,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 xinetd.man --- xinetd/xinetd.man 19 Feb 2003 17:29:28 -0000 1.1.1.1 +++ xinetd/xinetd.man 21 May 2003 21:06:27 -0000 @@ -82,6 +82,10 @@ .BI \-stayalive Tells xinetd to stay running even if no services are specified. .TP +.BI \-dontfork +Tells xinetd to stay in the foreground rather than detaching itself, to +support being run from init or daemontools. +.TP .BI \-limit " proc_limit" This option places a limit on the number of concurrently running processes that can be started by @@ -176,6 +180,8 @@ .I "xinetd.conf(5)," .LP .I "xinetd.log(5)" +.LP +.I "http://cr.yp.to/daemontools.html" .\" *********************** AUTHOR **************************** .SH AUTHOR Panos Tsirigotis, CS Dept, University of Colorado, Boulder -- Matthias Andree From dp at co.ru Thu May 22 06:54:19 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service Message-ID: <3ECCD68B.3B8F2ECA@co.ru> HI, There is another problem with 2.3.11: I have many TCP wait sevices. And sometimes some of them cann't start because it's config corrupted (by user). xinetd 2.3.0 simply deactivated such service forever(I made restart xinetd every 10min) with diagnostic: 03/5/22@17:32:47: ERROR: {svc_looping} s0001 service was deactivated because of looping But 2.3.11 behaviour worse: 1) select return ready for read fd for service 2) fork->exec->and child some times later fails (return code != 0) 3) because child hadn't made accept() -> go fo 1) so I have a endless loop of fork(). But sometimes loop ended in parent_access_control() with: Deactivating service s0001 due to excessive incoming connections. Restarting in 10 seconds. for ~10sec fork() stopped, and then started again. I made patch for this. But because cps_service_restart is static in access.c, I made local copy(very ugly) for it in service.c -- Dmitry Perfilyev -------------- next part -------------- *** server.c.orig ?? ??? 22 17:22:21 2003 --- server.c ?? ??? 22 17:22:21 2003 *************** *** 294,301 **** } /* Added this for when acceptint wait=yes services */ ! if( SVC_WAITS( sp ) ) FD_SET( SVC_FD( sp ), &ps.rws.socket_mask ) ; svc_postmortem( sp, serp ) ; server_release( serp ) ; --- 294,303 ---- } /* Added this for when acceptint wait=yes services */ ! /* if( SVC_WAITS( sp ) ) FD_SET( SVC_FD( sp ), &ps.rws.socket_mask ) ; + COMMENTED because we ALWAYS make FD_SET() later - in svc_resume() + */ svc_postmortem( sp, serp ) ; server_release( serp ) ; -------------- next part -------------- *** service.c.orig ?? ??? 22 17:22:21 2003 --- service.c ?? ??? 22 17:22:21 2003 *************** *** 835,840 **** --- 835,871 ---- return( OK ) ; } + /* This is called by the flags processor */ + static void cps_service_restart(void) + { + int i; + time_t nowtime; + const char *func = "cps_service_restart"; + + nowtime = time(NULL); + for( i=0; i < pset_count( SERVICES(ps) ); i++ ) { + struct service *sp; + struct service_config *scp; + + sp = pset_pointer( SERVICES(ps), i); + + if( sp->svc_state == SVC_DISABLED ) { + scp = SVC_CONF( sp ); + if ( scp->sc_time_reenable <= nowtime ) { + /* re-enable the service */ + if( svc_activate(sp) == OK ) { + msg(LOG_ERR, func, + "Activating service %s", scp->sc_name); + } else { + msg(LOG_ERR, func, + "Error activating service %s", + scp->sc_name) ; + } /* else */ + } + } + } /* for */ + } + /* * Invoked when a server of the specified service dies */ *************** *** 876,882 **** free(cp); cp = NULL; } ! svc_resume(sp); } } --- 907,932 ---- free(cp); cp = NULL; } ! /* ! scp - service_config * ! sp - service * ! serp - server * ! */ ! if ( serp->svr_exit_status != 0 ) ! { ! /* FD_SET( SVC_FD( sp ), &ps.rws.socket_mask ) ; */ ! struct service_config *scp; ! time_t nowtime; ! ! scp = SVC_CONF(sp); ! svc_deactivate(sp); ! msg(LOG_ERR, func, "Deactivating service %s due to bad server exit status. Restarting in %d seconds.", scp->sc_name, (int)scp->sc_time_wait); ! nowtime = time(NULL); ! scp->sc_time_reenable = nowtime + scp->sc_time_wait; ! xtimer_add(cps_service_restart, scp->sc_time_wait); ! } ! else ! svc_resume(sp); } } From linux_4ever at yahoo.com Thu May 22 07:26:15 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <3ECCD68B.3B8F2ECA@co.ru> Message-ID: <20030522142615.47495.qmail@web9602.mail.yahoo.com> Hello, Could you also send a sample config that causes the problem? I would like to do some testing to what happens before and after the patch. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From dp at co.ru Thu May 22 07:39:42 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service References: <20030522142615.47495.qmail@web9602.mail.yahoo.com> Message-ID: <3ECCE12E.F0C5D859@co.ru> Hello. sample conf: ------------------------------------------- defaults { log_type = FILE /tmp/x.log log_on_success = PID HOST DURATION log_on_failure = HOST } service s0001 { flags = REUSE socket_type = stream protocol = tcp wait = yes bind = 192.168.2.13 server = /bin/false type = UNLISTED port = 1236 user = test } ------------------------------------------- without patch - many fork(), with patch: 03/5/22@18:38:06: DEBUG: 26529 {cnf_start_services} Started service: s0001 03/5/22@18:38:06: DEBUG: 26529 {cnf_start_services} mask_max = 6, services_started = 1 03/5/22@18:38:06: NOTICE: 26529 {main} xinetd Version 20030122 started with no options compiled in. 03/5/22@18:38:06: NOTICE: 26529 {main} Started working: 1 available service 03/5/22@18:38:06: DEBUG: 26529 {main_loop} active_services = 1 03/5/22@18:38:08: DEBUG: 26529 {main_loop} select returned 1 03/5/22@18:38:08: DEBUG: 26529 {svc_suspend} Suspended service s0001 03/5/22@18:38:08: DEBUG: 26529 {server_start} Starting service s0001 03/5/22@18:38:08: DEBUG: 26529 {main_loop} active_services = 0 03/5/22@18:38:08: DEBUG: 26531 {exec_server} duping 6 03/5/22@18:38:08: DEBUG: 26529 {main_loop} active_services = 0 03/5/22@18:38:08: DEBUG: 26529 {main_loop} select returned 1 03/5/22@18:38:08: DEBUG: 26529 {check_pipe} Got signal 18 (Child Status Changed) 03/5/22@18:38:08: DEBUG: 26529 {child_exit} waitpid returned = 26531 03/5/22@18:38:08: DEBUG: 26529 {server_end} s0001 server 26531 exited 03/5/22@18:38:08: DEBUG: 26529 {deactivate} 26529 Service s0001 deactivated 03/5/22@18:38:08: ERROR: 26529 {svc_postmortem} Deactivating service s0001 due to bad server exit status. Restarting in 10 seconds. 03/5/22@18:38:08: DEBUG: 26529 {child_exit} waitpid returned = -1 03/5/22@18:38:08: DEBUG: 26529 {main_loop} active_services = 0 Steve G wrote: > > Hello, > > Could you also send a sample config that causes the > problem? I would like to do some testing to what happens > before and after the patch. > > Thanks, > -Steve Grubb -- Dmitry Perfilyev JSC Combellga www.co.ru From linux_4ever at yahoo.com Thu May 22 09:11:32 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <3ECCD68B.3B8F2ECA@co.ru> Message-ID: <20030522161132.67077.qmail@web9602.mail.yahoo.com> Hello, Thanks for the config. I see what you are talking about. Since the child did not accept the packet, the fd is still readable and select starts another cycle. The cps should kick in and deactivate the service for a specified amount of time and then restart the service. When this occurs, the listening descriptor is closed which dumps the data. After the timeout, it restart the service with a new fd. Looping does not not occur until another connection is made. What is wrong with the above scenario? Did you want the service permanently disabled? Did you want the cps to interrupt the service quicker? I just want to make sure I understand how your proposed solution differs from what I'm seeing. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From bbraun at synack.net Thu May 22 11:24:38 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030522161132.67077.qmail@web9602.mail.yahoo.com>; from linux_4ever@yahoo.com on Thu, May 22, 2003 at 09:11:32AM -0700 References: <3ECCD68B.3B8F2ECA@co.ru> <20030522161132.67077.qmail@web9602.mail.yahoo.com> Message-ID: <20030522112437.T3859@lh.synack.net> On Thu, May 22, 2003 at 09:11:32AM -0700, Steve G wrote: > Hello, > > Thanks for the config. I see what you are talking about. > > Since the child did not accept the packet, the fd is still > readable and select starts another cycle. The cps should > kick in and deactivate the service for a specified amount > of time and then restart the service. When this occurs, the > listening descriptor is closed which dumps the data. After > the timeout, it restart the service with a new fd. Looping > does not not occur until another connection is made. This seems like the correct behavior, however, it is possible on a slow, or loaded system that cps will *not* kick in because the machine is not able to loop the service fast enough. In this situation, the service will loop forever. This is a seemingly pathological case because you've either misconfigured your xinetd.conf for this service (it's marked wait=yes, when it shouldn't be), or you are running a server that is broken (should be accept()ing, but isn't). Arguably, cps should be set lower on such a machine, especially for wait=yes services. An equally valid argument is that xinetd should close the listening socket once it forks the wait=yes service (it has no business keeping it open anyway), and reenabling the socket when the service dies. This will prevent the infinite looping we're seeing, since the socket will be closed for good when the child dies, the client will disconnect, and all is well. Rob From linux_4ever at yahoo.com Thu May 22 14:39:20 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030522112437.T3859@lh.synack.net> Message-ID: <20030522213920.4876.qmail@web9607.mail.yahoo.com> >it is possible on a slow, or loaded system that cps will >*not* kick in because the machine is not able to loop the >service fast enough. This kind of where I was going. My machine running valgrind needed cps = 5 10 to kill the looping. Without valgrind the defaults are fine. I guess the drawback of stopping listening is that no connections will be queued for normal working servers. Which is worse, not getting connections queued for working servers or intermittant looping for buggy servers? I think most servers work or they will get the admins attention. Intermittanly denying connections (since fd was closed) will probably be a bigger headache. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From dp at co.ru Thu May 22 23:32:56 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service References: <20030522213920.4876.qmail@web9607.mail.yahoo.com> Message-ID: <3ECDC098.9C2A1E53@co.ru> Steve G wrote: > > >it is possible on a slow, or loaded system that cps will > >*not* kick in because the machine is not able to loop the > >service fast enough. > > This kind of where I was going. My machine running valgrind > needed cps = 5 10 to kill the looping. Without valgrind the > defaults are fine. > > I guess the drawback of stopping listening is that no > connections will be queued for normal working servers. > Which is worse, not getting connections queued for working > servers or intermittant looping for buggy servers? > > I think most servers work or they will get the admins > attention. Intermittanly denying connections (since fd was > closed) will probably be a bigger headache. Yes, there are two problem: 1) on loaded system with heavy sevice, machine is not able to loop the service fast enough. And cost of exec buggy service is big. (but it is not very critical) 2) Most serious - that xinetd does not care about return status of his child. Example: 1) we started tcp/wait service and it started OK. 2) time passed 3) child exited with exit code !=0 - I think it will be useful if xinetd disable service for a while. Perhaps need another service flag ? -- Dmitry Perfilyev JSC Combellga www.co.ru From ma+xi at dt.e-technik.uni-dortmund.de Fri May 23 05:00:27 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030522112437.T3859@lh.synack.net> (Rob Braun's message of "Thu, 22 May 2003 11:24:38 -0700") References: <3ECCD68B.3B8F2ECA@co.ru> <20030522161132.67077.qmail@web9602.mail.yahoo.com> <20030522112437.T3859@lh.synack.net> Message-ID: Rob Braun writes: > On Thu, May 22, 2003 at 09:11:32AM -0700, Steve G wrote: >> Since the child did not accept the packet, the fd is still >> readable and select starts another cycle. The cps should >> kick in and deactivate the service for a specified amount >> of time and then restart the service. When this occurs, the >> listening descriptor is closed which dumps the data. After >> the timeout, it restart the service with a new fd. Looping >> does not not occur until another connection is made. > > This is a seemingly pathological case because you've either > misconfigured your xinetd.conf for this service (it's marked > wait=yes, when it shouldn't be), or you are running > a server that is broken (should be accept()ing, but isn't). > for wait=yes services. An equally valid argument is that > xinetd should close the listening socket once it forks the > wait=yes service (it has no business keeping it open anyway), Well, "wait" isn't usually used for stream sockets (TCP) in inetd (quote from FreeBSD 4.8 inetd(8) manual), except for tcpmux: Servers using stream sockets generally are multi-threaded and use the ``nowait'' entry. Connection requests for these services are accepted by inetd, and the server is given only the newly-accepted socket connected to a client of the service. If there was a way for xinetd to figure if the server has called accept(2) at least once, then xinetd would have the chance of extracting and discarding the connection request itself if the child process failed to do so. I fear select() isn't up to the job, because that might just return "input data waiting" for a subsequent yet valid request, and I have been unable to peek at the listening socket. I wonder what data a non-blocking recv(sock, buff, size, MSG_PEEK) would stuff in buff for TCP sockets. If TCP or IP sequence numbers are available (before accept), then a non-blocking recv() after the child has exited could give a hint whether accept() was called. > and reenabling the socket when the service dies. This will > prevent the infinite looping we're seeing, since the socket > will be closed for good when the child dies, the client will > disconnect, and all is well. Well, a client that sends its connect() between closing and reopening the listen() socket will get connection refused, which isn't right either. -- Matthias Andree From linux_4ever at yahoo.com Fri May 23 05:36:09 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: Message-ID: <20030523123609.75761.qmail@web9606.mail.yahoo.com> Hello, >Well, "wait" isn't usually used for stream sockets (TCP) >in inetd Its also valid to have wait for tcp services if they use files or other resources in an unsafe way. This goes back to the days of commercial unix when you may not have source code to fix the problem. I think the correct solution for this problem is to document it in a FAQ or something and not touch the code. If we do touch the code, it should only be to log the exit status of the child and nothing more. Would this satisfy everyone? -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From dp at co.ru Fri May 23 06:07:17 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> Message-ID: <3ECE1D05.5EDFD6C5@co.ru> > Hello, > > >Well, "wait" isn't usually used for stream sockets (TCP) > >in inetd > > Its also valid to have wait for tcp services if they use > files or other resources in an unsafe way. This goes back > to the days of commercial unix when you may not have source > code to fix the problem. > > I think the correct solution for this problem is to > document it in a FAQ or something and not touch the code. > If we do touch the code, it should only be to log the exit > status of the child and nothing more. Would this satisfy > everyone? I think that currently realization of "wait" service, not "clean". now: 1) main_loop() does select() 2) svc_request() -> set service status SUSPEND -> fork() -> exec() 3) again with 1) until child's accept() but for "wait" service (which have only child for service) more suitable next way: 1) main_loop() does select() 2) chech if service "wait" and it's status SUSPEND - next 1) 3) svc_request() -> set service status SUSPEND -> fork() -> exec() 4) again with 1) *) wnen catch SIGCHLD - check return code. if 0 - status=ACTIVE, if !=0 - deactivate service for a while. so, we get rid of fork(), and take care of child return status. Sorry for my English. -- Dmitry Perfilyev JSC Combellga www.co.ru From keith_gaughan at freddiemac.com Fri May 23 09:03:25 2003 From: keith_gaughan at freddiemac.com (keith_gaughan@freddiemac.com) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Keith B Gaughan/CONSULT/HQ/FHLMC is out of the office. Message-ID: I will be out of the office starting 05/23/2003 and will not return until 05/26/2003. I will respond to your message upon my return. From ma+xi at dt.e-technik.uni-dortmund.de Fri May 23 10:33:31 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030523123609.75761.qmail@web9606.mail.yahoo.com> (Steve G.'s message of "Fri, 23 May 2003 05:36:09 -0700 (PDT)") References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> Message-ID: Steve G writes: > Hello, > >>Well, "wait" isn't usually used for stream sockets (TCP) >>in inetd > > Its also valid to have wait for tcp services if they use > files or other resources in an unsafe way. This goes back > to the days of commercial unix when you may not have source > code to fix the problem. > > I think the correct solution for this problem is to > document it in a FAQ or something and not touch the code. > If we do touch the code, it should only be to log the exit > status of the child and nothing more. Would this satisfy > everyone? I can also fancy an throttle for such cases, for the concept, look at the "Token Bucket Filter" that Linux' netfilter does. The concept is like this: it starts with a certain (the maximum) amount of tokens, which refill at a certain constant rate (for example 5/s) unless the maximum of tokens is present. Each start of the service takes away a token, and if no tokens are present, the next service start is delayed until one token has been refilled (1/5 s in this case). If you put the start value higher, this will give room for "bursty" client behaviour but ultimately throttle the service starts to the configured rate asymptotically under sustained load. It's a "smoothed" refinement on the "cps" that doesn't place a hard "service gone" delay but a softer "don't start more than five times per second" one. Random delays between select() and accept() can also help. Rob's suggestion of closing the listening socket won't work BTW; because in "wait" mode, the daemon expects to receive the listen socket, not the accept socket, and the "wait" daemon itself can choose to extract the next connection itself. As far as I understand it, this listen socket is never closed. -- Matthias Andree From bbraun at synack.net Fri May 23 10:42:33 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Fri, May 23, 2003 at 07:33:31PM +0200 References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> Message-ID: <20030523104233.U3859@lh.synack.net> On Fri, May 23, 2003 at 07:33:31PM +0200, Matthias Andree wrote: > > Rob's suggestion of closing the listening socket won't work BTW; because > in "wait" mode, the daemon expects to receive the listen socket, not the > accept socket, and the "wait" daemon itself can choose to extract the > next connection itself. As far as I understand it, this listen socket is > never closed. It's not, really, ever closed. Daemon bind()s, listen()s, gets a connection, forks, child accept()s, does whatever. Daemon close()s the listen socket. When the child dies, the daemon reopens the socket, bind()s, listen()s, and starts the process all over again. There are a couple of problems with this 'solution', but it definitely works in the general case. I've got diffs. =) This way, the client is required to accept() all outstanding connections before exiting. Usually, this isn't a problem because the daemon wouldn't be wait=yes if it wasn't meant to be persistent. However, even if the daemon does this, there is a time when the daemon died and xinetd re-enables the socket, when connections will be refused. Rob From ma+xi at dt.e-technik.uni-dortmund.de Fri May 23 13:51:38 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030523104233.U3859@lh.synack.net> (Rob Braun's message of "Fri, 23 May 2003 10:42:33 -0700") References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> <20030523104233.U3859@lh.synack.net> Message-ID: Rob Braun writes: > On Fri, May 23, 2003 at 07:33:31PM +0200, Matthias Andree wrote: >> >> Rob's suggestion of closing the listening socket won't work BTW; because >> in "wait" mode, the daemon expects to receive the listen socket, not the >> accept socket, and the "wait" daemon itself can choose to extract the >> next connection itself. As far as I understand it, this listen socket is >> never closed. > > It's not, really, ever closed. Daemon bind()s, listen()s, > gets a connection, forks, child accept()s, does whatever. Well, the question is: does the daemon really close the listen socket? In FreeBSD's inetd, it doesn't. (unless you set nowait, of course). > to be persistent. However, even if the daemon does this, > there is a time when the daemon died and xinetd re-enables > the socket, when connections will be refused. If the daemon kept the LISTEN socket open, there wouldn't be such a problem. (And the child's close() shouldn't affect that parent's socket, or am I mistaken here?) -- Matthias Andree From bbraun at synack.net Fri May 23 17:11:09 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Fri, May 23, 2003 at 10:51:38PM +0200 References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> <20030523104233.U3859@lh.synack.net> Message-ID: <20030523171109.W3859@lh.synack.net> On Fri, May 23, 2003 at 10:51:38PM +0200, Matthias Andree wrote: > > > > It's not, really, ever closed. Daemon bind()s, listen()s, > > gets a connection, forks, child accept()s, does whatever. > > Well, the question is: does the daemon really close the listen socket? > In FreeBSD's inetd, it doesn't. (unless you set nowait, of course). Right now, xinetd does not close the socket. In the scenario being discussed, it would. > If the daemon kept the LISTEN socket open, there wouldn't be such a > problem. (And the child's close() shouldn't affect that parent's socket, > or am I mistaken here?) Correct, there would not be such a problem, but you have exactly the scenario we have now. Forked server doesn't accept, client is still connected, forked server dies, xinetd still sees the client, forks a new server, which starts the cycle all over again. Rob From ma+xi at dt.e-technik.uni-dortmund.de Fri May 23 19:28:04 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: <20030523171109.W3859@lh.synack.net> (Rob Braun's message of "Fri, 23 May 2003 17:11:09 -0700") References: <20030523123609.75761.qmail@web9606.mail.yahoo.com> <20030523104233.U3859@lh.synack.net> <20030523171109.W3859@lh.synack.net> Message-ID: Rob Braun writes: > Correct, there would not be such a problem, but you have exactly the > scenario we have now. Forked server doesn't accept, client is still > connected, forked server dies, xinetd still sees the client, forks > a new server, which starts the cycle all over again. How about a throttling for the restart rate as suggested previously? It doesn't interrupt service, but limit the amount of forks we're doing. It doesn't stop the problem, but reduce its impact. On slower machines, such a fork loop is _evil_. -- Matthias Andree From dp at co.ru Wed May 28 01:46:53 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] bug in readjust() Message-ID: <3ED4777D.A6684183@co.ru> Hi! Another bug. Solaris8, IPv4, gcc2.95.3, tcp_wait service s001. 1) xinetd started service s001 2) while service is working xinetd get SIGHUP sighal 3) xinetd call check_pipe()->hard_reconfig()->readjust() and in reajust() check: if( (old_conf->sc_bind_addr != NULL) && (new_conf->sc_bind_addr != NULL) ) { if( memcmp( old_conf->sc_bind_addr, new_conf->sc_bind_addr, sizeof(union xsockaddr)) != 0) { terminate_servers( sp ); svc_deactivate(sp); svc_activate(sp); return( restart_log( sp, old_conf ) ) ; } } but sizeof(union xsockaddr) return 128, however in IPv4 the same only sizeof(struct sockaddr_in) == 16 bytes. So, memcmp() returns 1 and my service got SIGKILL. When I change code to sizeof(struct sockaddr_in) - everything OK. in gdb5.3: (ONLY first 16bytes match !) (gdb) x/128xb old_conf->sc_bind_addr 0x5bb30: 0x00 0x02 0x00 0x00 0xc0 0xa8 0x02 0x0d 0x5bb38: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x5bb40: 0x00 0x05 0xbb 0x54 0x31 0x39 0x32 0x2e 0x5bb48: 0x31 0x36 0x38 0x2e 0x32 0x2e 0x31 0x33 0x5bb50: 0x00 0x30 0x33 0x2f 0x00 0x05 0xc4 0x60 0x5bb58: 0x00 0x00 0x00 0x00 0x2f 0x2a 0x20 0x53 0x5bb60: 0x56 0x72 0x34 0x2e 0x30 0x20 0x31 0x2e 0x5bb68: 0x31 0x09 0x2a 0x2f 0x0a 0x0a 0x23 0x0a 0x5bb70: 0x23 0x20 0x49 0x6e 0x74 0x65 0x72 0x6e 0x5bb78: 0x65 0x74 0x20 0x28 0x49 0x50 0x29 0x20 0x5bb80: 0x70 0x72 0x6f 0x74 0x6f 0x63 0x6f 0x6c 0x5bb88: 0x73 0x0a 0x23 0x0a 0x69 0x70 0x09 0x09 0x5bb90: 0x30 0x09 0x49 0x50 0x09 0x09 0x23 0x20 0x5bb98: 0x69 0x6e 0x74 0x65 0x72 0x6e 0x65 0x74 0x5bba0: 0x20 0x70 0x72 0x6f 0x74 0x6f 0x63 0x6f 0x5bba8: 0x6c 0x2c 0x20 0x70 0x73 0x65 0x75 0x64 (gdb) x/128xb new_conf->sc_bind_addr 0x62590: 0x00 0x02 0x00 0x00 0xc0 0xa8 0x02 0x0d 0x62598: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x625a0: 0x00 0x06 0x25 0xb4 0x31 0x39 0x32 0x2e 0x625a8: 0x31 0x36 0x38 0x2e 0x32 0x2e 0x31 0x33 0x625b0: 0x00 0x31 0x2e 0x31 0x00 0x06 0x2e 0xc0 0x625b8: 0x00 0x00 0x00 0x00 0x32 0x35 0x20 0x53 0x625c0: 0x4d 0x49 0x22 0x0a 0x23 0x0a 0x23 0x20 0x625c8: 0x54 0x68 0x65 0x20 0x22 0x4e 0x65 0x74 0x625d0: 0x77 0x6f 0x72 0x6b 0x20 0x43 0x6f 0x6e 0x625d8: 0x66 0x69 0x67 0x75 0x72 0x61 0x74 0x69 0x625e0: 0x6f 0x6e 0x22 0x20 0x46 0x69 0x6c 0x65 0x625e8: 0x2e 0x0a 0x23 0x0a 0x23 0x20 0x45 0x61 0x625f0: 0x63 0x68 0x20 0x65 0x6e 0x74 0x72 0x79 0x625f8: 0x20 0x69 0x73 0x20 0x6f 0x66 0x20 0x74 0x62600: 0x68 0x65 0x20 0x66 0x6f 0x72 0x6d 0x3a 0x62608: 0x0a 0x23 0x0a 0x23 0x20 0x20 0x20 0x20 -- Dmitry Perfilyev P.S. What about wait services and fork() problem : http://www.xinetd.org/pipermail/xinetd/2003-May/000097.html Am I wrong anywhere ? Although workaround with cps = 2 10 seems to be worked. From linux_4ever at yahoo.com Wed May 28 05:31:36 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] bug in readjust() In-Reply-To: <3ED4777D.A6684183@co.ru> Message-ID: <20030528123136.25131.qmail@web9602.mail.yahoo.com> >if( memcmp( old_conf->sc_bind_addr, >new_conf->sc_bind_addr, sizeof(union xsockaddr)) != 0) That definitely looks wrong. I just put a corrected reconfig.c in cvs. Good catch. >P.S. What about wait services and fork() problem My opinion is that the bad xinetd behavior is a combination of a bad server program that requires wait, and the limitations of what tcp/ip provides as an API. I do not like any of the solutions presented and I'm reluctant to change the code and break "good" servers for a buggy server. There's far more good servers than buggy ones or we'd see this reported more often. What's really required to solve this problem is the ability to determine if a descriptor has been accepted by the child and drain it if not. Anything else is a hack that will cause problems for someone and will cause functionality changes. I'm not trying to upset anyone, but rate limits dance around the problem without fixing it. Every admin will have to tune the limit for his own environment. I've fixed many bugs in xinetd 2.3.11 so far and I hope that we can get a 2.3.12 released without behavior changes. Rob may have a different opinion, but I think its best to wait until a good solution presents itself. I personally want 2.3.12 to be a pure bug fix release and no functionality changes. Thanks for reporting the readjust bug! -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From linux_4ever at yahoo.com Wed May 28 08:16:39 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] fork() flood in tcp/wait service In-Reply-To: Message-ID: <20030528151639.29569.qmail@web9604.mail.yahoo.com> Hello, Based on earlier discussion, here's the proposals: 1) Catch the return value of the child process and stop the service if the child returns 1. 2) Throttle the connections. 3) Close the listen socket until 1st connection ends. The problem I see with each is: 1) Xinetd should not care about return code. What if server returns 1 to indicate that the username/password failed? We are guessing that 1 means it did not accept the connection. We could break a lot of applications with this. 2) We already have cps which is more or less the same thing as rate throttling. (The algorithm is different, but the net result is the same.) The problem is that it's site specific as to what value causes problems. Adding a new rate throttle increases the xinetd code and adds something else that must be tuned. For example, when cps is too low, this mail list gets problem reports saying the cps is killing servers when it shouldn't. Now we set it higher and people say busy servers can't loop fast enough for it to kick in. With rate throttling, the listen queue is only so long, so it sends a RST back to the client when its full. How does a system admin debug that? Then, the initial connection still cycles over and over, but at a slower rate. The data is still not accepted. The problem will not clear until the initial client disconnects. Then the next in in the queue will do the same. You could almost get the same effect by wrapping the buggy service with a shell script that sleeps for a second before exec'ing the server. There's no way to satisfy both cases since they are at opposite ends of the spectrum. It will always be site specific. 3) This aborts connections that would otherwise be queued and handled. I would predict that we will get bug reports saying that client applications report connections denied when they shouldn't have. The system admin will have no debug information to work with and they will probably start looking at hosts.allow & deny, firewalls, service settings, the application, and may not be able to reproduce the problem. It will be difficult to tell what the problem is. Can anyone think of another way to solve the problem? Should this even be considered an xinetd problem? What about contacting authors of the buggy wait server and ask them to call accept right away and then do any other setups? Should we just document this is a problem and how to tune the settings for it? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Wed May 28 12:54:03 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? Message-ID: Hi, is my dontfork patch I posted a week ago considered for inclusion into 2.3.12? (I haven't yet got _any_ feedback.) It would allow running xinetd from daemontools or init. In case someone missed my mail, the patch has been updated a minute ago to the current CVS version, find it at: http://mandree.home.pages.de/xinetd/add-dontfork-option.diff Cheers, -- Matthias Andree From linux_4ever at yahoo.com Wed May 28 15:10:57 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: Message-ID: <20030528221057.9003.qmail@web9607.mail.yahoo.com> Hello Matthias, I'm not sure about the patch. I think Rob should give some feedback, too. On the surface, the patch seems simple enough and low risk. Personally, I'm not too much in favor of this since all deamons are *supposed* to fork and detach from controlling terminals. Daemontools seems misnamed if it requires violation of the basic premise of daemon startup. I'm not sure what kind of new problems we will be dealing with by not forking. I'd need to doublecheck that everything is really safe, no controlling ttys, etc. If you restart the daemon in x windows & resize the terminal window, do signals get sent to xinetd? There's a lot of little things like that we need to check. Does daemon tools send job control signals? What does marrying up to it really mean? I don't use daemontools so I can't really determine what we would be getting into. But not to sound too bleak...there are a few people that use daemontools and they would find this useful. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From bbraun at synack.net Wed May 28 15:45:47 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528221057.9003.qmail@web9607.mail.yahoo.com>; from linux_4ever@yahoo.com on Wed, May 28, 2003 at 03:10:57PM -0700 References: <20030528221057.9003.qmail@web9607.mail.yahoo.com> Message-ID: <20030528154547.Z3859@lh.synack.net> On Wed, May 28, 2003 at 03:10:57PM -0700, Steve G wrote: > > Personally, I'm not too much in favor of this since all > deamons are *supposed* to fork and detach from controlling > terminals. Daemontools seems misnamed if it requires > violation of the basic premise of daemon startup. Well, I think in some of the cases mentioned, there is no controlling tty to detatch from, so it's not a big deal. I'm actually in favor of the patch, keeping in mind some of the concerns you've raised. Starting xinetd with this option from a shell seems like a silly thing to do, and bugs with that configuration should probably not prevent the patch from being integrated. We should probably still fix any problem that arises with such a configurations, so that xinetd doesn't totally bork under those circumstances, but I don't see preventing the patch because of it. However, making sure that it does work in the situations where it does make sense, such as launching xinetd from init, or with daemontools is a valid concern. I'm of the opinion that the patch should be integrated so that it can recieve wider testing. Rob From fenlason at redhat.com Wed May 28 16:10:18 2003 From: fenlason at redhat.com (Jay Fenlason) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528221057.9003.qmail@web9607.mail.yahoo.com> References: <20030528221057.9003.qmail@web9607.mail.yahoo.com> Message-ID: <20030528231018.GB31464@redhat.com> On Wed, May 28, 2003 at 03:10:57PM -0700, Steve G wrote: > Hello Matthias, > > I'm not sure about the patch. I think Rob should give some > feedback, too. On the surface, the patch seems simple > enough and low risk. Personally, I'm in favor of this patch. It makes it much easier to run xinetd under GDB. Isn't that a good enough reason? > Personally, I'm not too much in favor of this since all > deamons are *supposed* to fork and detach from controlling > terminals. Daemontools seems misnamed if it requires > violation of the basic premise of daemon startup. I use daemontools at home. Red Hat doesn't ship daemontools because DJB's licensing makes it difficult (impossible? I haven't re-read his license lately) for us to do so, so what I'm saying below is while wearing my hobbyist baseball cap instead of my crimson fedora. Think of daemontools as a replacement for init(8) and you'll understand it better. It does the detaching from the console etc so that the individual daemons don't have to, automatically sets up stdout/stderr logging for them (if configured to), etc. (Like init) it also restarts daemons when they exit. Unfortunatly, a daemon than forks looks exactly like a daemon that exits to the master control program, so it starts another one. . . Boom. Unlike init it doesn't have runlevels, but it does have commands for manually starting, stopping, etc individual programs. The servers run as children of the daemontools master process, so they inherit it's (lack of a) controlling terminal, process group, etc. > I'm not sure what kind of new problems we will be dealing > with by not forking. I'd need to doublecheck that > everything is really safe, no controlling ttys, etc. If you > restart the daemon in x windows & resize the terminal > window, do signals get sent to xinetd? There's a lot of > little things like that we need to check. Does daemon tools > send job control signals? What does marrying up to it > really mean? I don't use daemontools so I can't really > determine what we would be getting into. If the user starts xinetd in non-forking mode they need to know what they're doing. Daemontools takes care of the details. If I'm running it under GDB I'll just have to take my chances. As long as the man page is clear on what the option does, if anyone else turns on the --dont-fork option and shoots themself in the foot, we can tell them to RTFM. > But not to sound too bleak...there are a few people that > use daemontools and they would find this useful. Ayup. I regularly patch programs I want to run under daemontools to do what I want, but not everybody can do that, eh? -- JF From bbraun at synack.net Wed May 28 16:15:33 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528231018.GB31464@redhat.com>; from fenlason@redhat.com on Wed, May 28, 2003 at 07:10:18PM -0400 References: <20030528221057.9003.qmail@web9607.mail.yahoo.com> <20030528231018.GB31464@redhat.com> Message-ID: <20030528161533.A3859@lh.synack.net> On Wed, May 28, 2003 at 07:10:18PM -0400, Jay Fenlason wrote: > > Personally, I'm in favor of this patch. It makes it much easier to > run xinetd under GDB. Isn't that a good enough reason? The -d option is the debugging option, which makes xinetd not fork. This is perfectly fine for debugging purposes, and I'd rather not use debugging as justification for this new option. If you're debugging and -d doesn't do what you want it to, we should look at making -d more friendly to debugging. Rob From linux_4ever at yahoo.com Wed May 28 16:18:29 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528154547.Z3859@lh.synack.net> Message-ID: <20030528231829.24453.qmail@web9602.mail.yahoo.com> >I'm of the opinion that the patch should be integrated >so that it can recieve wider testing. Do you want to put it in cvs or do you want me to do it? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From linux_4ever at yahoo.com Wed May 28 18:03:25 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528231829.24453.qmail@web9602.mail.yahoo.com> Message-ID: <20030529010325.25904.qmail@web9605.mail.yahoo.com> >Do you want to put it in cvs or do you want me to do it? I went ahead and put it in cvs. Everyone, please give it a good test from the commandline. There's a small chance this could introduce a subtle bug and it would be good to catch it now. todo is done :) -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Thu May 29 05:28:16 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030528221057.9003.qmail@web9607.mail.yahoo.com> (Steve G.'s message of "Wed, 28 May 2003 15:10:57 -0700 (PDT)") References: <20030528221057.9003.qmail@web9607.mail.yahoo.com> Message-ID: Steve G writes: > Personally, I'm not too much in favor of this since all > deamons are *supposed* to fork and detach from controlling > terminals. I wonder what legal basis this stands upon. Forking daemons means you can't control them reliably. > Daemontools seems misnamed if it requires violation of the basic > premise of daemon startup. Nope. Daemontools (and init) both feature instant-restart when the daemon dies, that's something you cannot have with daemons that detach themselves. Those .pid files that daemons must write are a poor crutch to the real solution, when the daemon has died, no-one guarantess the .pid file is removed, and kill `cat /var/run/blah.pid` which is part of "/etc/init.d/foo restart" may well shoot your long-lasting simulation software right in the head. daemontools and daemons run from init solve this problem for good. Daemontools or init started services run in init's environment, so there are no nasty surprises with different PATH or other environment variable that are set in your root shell but not when /etc/init.d/* runs at boot-time. > I'm not sure what kind of new problems we will be dealing > with by not forking. None unless the user enables the option. Mark it as experimental if you don't trust it. > I'd need to doublecheck that everything is really safe, no controlling > ttys, etc. If you restart the daemon in x windows & resize the > terminal window, do signals get sent to xinetd? SIGWINCH? Probably. However, init or daemontools never send that signal. > There's a lot of little things like that we need to check. Does daemon > tools send job control signals? No. It only sends signal if the administrator requests it to, by means of the "svc" program. > What does marrying up to it really mean? I don't use daemontools so I > can't really determine what we would be getting into. You should have a look. Or have a look at a SysV init(8) (such as Solaris or SuSE Linux), in particular at its "respawn" mode in /etc/inittab. http://cr.yp.to/daemontools/faq/create.html#why Also check runit at http://smarden.org/pape/ -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Thu May 29 05:38:51 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030529010325.25904.qmail@web9605.mail.yahoo.com> (Steve G.'s message of "Wed, 28 May 2003 18:03:25 -0700 (PDT)") References: <20030529010325.25904.qmail@web9605.mail.yahoo.com> Message-ID: Steve G writes: >>Do you want to put it in cvs or do you want me to do it? > > I went ahead and put it in cvs. Everyone, please give it a > good test from the commandline. There's a small chance this > could introduce a subtle bug and it would be good to catch > it now. No, you should *NOT* run it from a shell, but either stick it into inittab or run it from daemontools. Example inittab line: XI:345:respawn:/usr/local/sbin/xinetd -dontfork -stayalive -- Matthias Andree From linux_4ever at yahoo.com Thu May 29 10:46:35 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: Message-ID: <20030529174635.60942.qmail@web9602.mail.yahoo.com> >> Personally, I'm not too much in favor of this since all >> deamons are *supposed* to fork and detach from controlling >> terminals. > >I wonder what legal basis this stands upon. Forking >daemons means you can't control them reliably. This comes from section 13.3 of Advanced programming in the Unix Environment, Richard Stevens. Its the standard reference. One of the things I'm curious about is the setsid call. It requires that the program not currently be the process group leader. Fork takes care of making sure its not a leader. >>Everyone, please give it a good test from the commandline. > >No, you should *NOT* run it from a shell, but either stick >it into inittab or run it from daemontools. Or gdb. Right, the man page says to run from init or daemontools. But on the otherhand, if people run it from the command line we need to know what problems pop up. Sooner or later someone will write asking for support because they did just that. I wonder what happens if xinetd cores or exits when running from init. Does the machine become unusable (from constant respawning)? What if they forget to put stayalive and there's no services? Should stayalive be automatically set by the code when dont_fork is enabled? There's a lot of little details that need looking at. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From linux_4ever at yahoo.com Fri May 30 12:01:33 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] Another resource leak Message-ID: <20030530190133.19039.qmail@web9606.mail.yahoo.com> Hello, I just wanted to let everyone know that I found and fixed another pretty good resource leak. It turns out that if you use "log_type = FILE" as a logging option, you will lose 1 file descriptor & 44 bytes of memory per service when you do a reload (SIGHUP). Valgrind output: ==15509== 44 bytes in 1 blocks are definitely lost in loss record 30 of 55 ==15509== at 0x400254E6: malloc (vg_replace_malloc.c:153) ==15509== by 0x805E0DD: xlog_create (xlog.c:63) ==15509== by 0x8051BAC: start_filelog (logctl.c:29) ==15509== by 0x8051D94: log_start (logctl.c:112) ==15509== by 0x8057D46: svc_activate (service.c:385) ==15509== by 0x804D593: cnf_start_services (conf.c:162) ==15509== by 0x80502A3: init_services (init.c:362) ==15509== by 0x8051E17: main (main.c:49) This can be significant if you have a lot of services and change your config frequently and only send SIGHUP. On a Red Hat system, this is the reload service option. The effect is cumulative and eventually you will run out of file descriptors. If you do not use "log_type = FILE", then you are not affected. This problem is not remotely exploitable and only the system admin can cause a reload. Also, if you stop and start xinetd or restart xinetd when updating your config, then you are not affected. So, my estimation is that this is more of an annoyance than anything else. The cvs version of xinetd is corrected and you may try it out. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Sat May 31 16:41:30 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] 2.3.12 todo? In-Reply-To: <20030529174635.60942.qmail@web9602.mail.yahoo.com> (Steve G.'s message of "Thu, 29 May 2003 10:46:35 -0700 (PDT)") References: <20030529174635.60942.qmail@web9602.mail.yahoo.com> Message-ID: Steve G writes: >>> Personally, I'm not too much in favor of this since all >>> deamons are *supposed* to fork and detach from > controlling >>> terminals. >> >>I wonder what legal basis this stands upon. Forking >>daemons means you can't control them reliably. > > This comes from section 13.3 of Advanced programming in the > Unix Environment, Richard Stevens. Its the standard > reference. Frankly, I don't care. Forking has proven to be a bad idea, and it's not necessary either, any reasonable shell can detach a child process, and duplicating functionality (detach) that's already present isn't reasonable. > One of the things I'm curious about is the setsid call. It > requires that the program not currently be the process > group leader. Fork takes care of making sure its not a > leader. There is a "supervise" process that forks and execs a "run" shell or perl script which in turn execs into the actual daemon after setting up file descriptors, resource limits and such. So process group leadership ought not to be a problem here. > Or gdb. Right, the man page says to run from init or > daemontools. But on the otherhand, if people run it from > the command line we need to know what problems pop up. They run it outside the specs, they take the risk and the blame. The documentation for that option is short and precise enough. Depends on what xinetd does when its file descriptors are closed, unhandled signals (SIGHUP perhaps) arrive. > I wonder what happens if xinetd cores or exits when running > from init. Does the machine become unusable (from constant > respawning)? No, init will try to restart the program (xinetd) a limited number of times (IIRC 10 times within 120 s) and then disable it for a couple of minutes. daemontools will instead sleep for some seconds after the daemon has exited, to yield the CPU. > What if they forget to put stayalive and there's no services? Should Again, then they haven't read the manual and deserve to suffer. We can't envision every possible stupid thing a root user might do, if they want to twist their system, they can. > stayalive be automatically set by the code when dont_fork is enabled? I've wondered about that one, too, but I'd thought putting this in the man page was good enough. Such automatisms get into somebody's way sooner or later, so I try to avoid these. I can also fancy killing the stayalive option and behave as though -stayalive was always there. After all, root can send a SIGTERM if he wants to get rid of the idle xinetd that serves no purpose. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Sat May 31 16:59:59 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] critical compile fix for CVS Message-ID: The CVS version doesn't currently compile on my computer, here's the fix: Index: xinetd/connection.h =================================================================== RCS file: /cvs/xinetd/xinetd/xinetd/connection.h,v retrieving revision 1.2 diff -u -r1.2 connection.h --- xinetd/connection.h 27 Feb 2003 22:33:48 -0000 1.2 +++ xinetd/connection.h 31 May 2003 23:58:56 -0000 @@ -92,7 +92,7 @@ connection_s *conn_new(struct service *sp); void conn_free(connection_s *cp, int); void conn_dump(const connection_s *cp,int fd); -char *conn_addrstr( const connection_s *cp ); +const char *conn_addrstr( const connection_s *cp ); #endif /* CONNECTION_H */ -- Matthias Andree From linux_4ever at yahoo.com Sat May 31 18:41:00 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:51 2005 Subject: [xinetd] critical compile fix for CVS In-Reply-To: Message-ID: <20030601014100.18775.qmail@web9603.mail.yahoo.com> >The CVS version doesn't currently compile on my computer, I forgot to check that file in. Thanks. I've been working on the warning messages produced when you compile using "make debug 2> warnings.txt" 2.3.11 produces 561 lines of of warnings, the copy on my machine now produces 322 lines of warnings. I've almost got the number in half and I think I can get it below 300 tomorrow. As a result of cleaning up the const messages, xinetd is a little smaller even though the cvs copy has more lines of xinetd code than 2.3.11. I think gcc was able to move some text strings from text segment to read only segment. Thanks again for the heads up. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com