Bug 16076

Summary: xinetd wait=yes doesn't work
Product: [Retired] Red Hat Linux Reporter: Neil Darlow <neil>
Component: xinetdAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-08-16 13:05:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Neil Darlow 2000-08-12 20:06:17 UTC 
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.
Comment 1 Neil Darlow 2000-08-13 06:48:33 UTC 
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.
Comment 2 Trond Eivind Glomsrxd 2000-08-13 15:56:59 UTC 
what does your configuration file look like? (Oh - and please bring the problem
up on the xinetd-list)
Comment 3 Preston Brown 2000-08-15 16:56:59 UTC 
trond, are we gonna use this release of xinetd?
Comment 4 Trond Eivind Glomsrxd 2000-08-15 17:00:58 UTC 
It has been in for some time (Aug 3)
Comment 5 Neil Darlow 2000-08-15 18:21:03 UTC 
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.
Comment 6 Neil Darlow 2000-08-16 13:05:32 UTC 
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.
Comment 7 Trond Eivind Glomsrxd 2000-08-16 13:34:04 UTC 
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.