xinetd-2.1.8.9pre8 After experiencing problems using wait=yes in an xinetd configuration file, I contacted the xinetd mailing list and received the following reply from Rob Braun: > It's not anything you're doing. xinetd doesn't work quite right > with wait=yes. I have a fix, and the next prerelease of xinetd will > have that fix in it. Theres a couple more things I'd like to track > down before releasing the next version though. Hopefully in the > next couple of days. For a quick fix, you can probably put wait=no. > > Rob Using wait=no isn't a usable fix for my application. Unless RC1 has a more recent xinetd than Pinstripe, it's a relevant issue.
xinetd-2.1.8.9pre9 fixes errors: warning: can't find client address: Invalid argument service afmbackup was deactivated because of looping The service still doesn't work though Same setup works with inetd under Red Hat 6.2.
what does your configuration file look like? (Oh - and please bring the problem up on the xinetd-list)
trond, are we gonna use this release of xinetd?
It has been in for some time (Aug 3)
Red Hat 6.2 inetd.conf entry (works): afmbackup stream tcp wait root /usr/local/afbackup-3.2.6/server/bin/afmserver /usr/local/afbackup-3.2.6/server/bin/afmserver /usr/local/afbackup-3.2.6/server/lib/backup.conf Pinstripe /etc/xinetd.d/afmbackup file (doesn't work): # default: on # # description: AFBackup multi-stream service. service afmbackup { socket_type = stream protocol = tcp wait = yes user = root server = /usr/local/afbackup-3.2.6/server/bin/afmserver server_args = /usr/local/afbackup-3.2.6/server/lib/backup.conf } /etc/services entry is identical for both 6.2 and Pinstripe: afmbackup 2989/tcp afmbackup 2989/udp I don't think udp is used but it seems normal to include both entries.
Rob Braun seems confident that wait=yes works now. The AFBackup author is going to work-around my problem by running the afmserver daemon stand-alone. The other possiblity is to ship both xinetd and inetd on the CD. I suggest this because the docs for xinetd claim that RPC services aren't well supported by xinetd and a solution is to run them via inetd from the xinetd service configuration file. This would go a long way towards providing support for difficult applications and limit Red Hat's exposure should xinetd be found to be at fault.
We're not going to ship both (besides, our package listing has been frozen a long time for translators, docs. etc). OK, I close this as partly application, partly fixed by the current release.