Red Hat Bugzilla – Bug 16076
xinetd wait=yes doesn't work
Last modified: 2008-05-01 11:37:57 EDT
After experiencing problems using wait=yes in an xinetd configuration file,
I contacted the xinetd mailing list and received the following reply from
> 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.
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-188.8.131.52pre9 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
Pinstripe /etc/xinetd.d/afmbackup file (doesn't work):
# default: on
# description: AFBackup multi-stream service.
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:
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.