Bug 16076 - xinetd wait=yes doesn't work
xinetd wait=yes doesn't work
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-12 16:06 EDT by Neil Darlow
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-16 09:05:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil Darlow 2000-08-12 16:06:17 EDT
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 02:48:33 EDT
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 11:56:59 EDT
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 12:56:59 EDT
trond, are we gonna use this release of xinetd?
Comment 4 Trond Eivind Glomsrxd 2000-08-15 13:00:58 EDT
It has been in for some time (Aug 3)
Comment 5 Neil Darlow 2000-08-15 14:21:03 EDT
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 09:05:32 EDT
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 09:34:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.