RE: Any way to do this with xinetd?

> 
> What's your daemon? Its easier to help when I know what you 
> are trying to do. Basically, disable your daemon from 
> starting up in the init scripts & kill all instances of it, 
> then fill in a service configuration in the /etc/xinetd.d 
> directory. Your xinetd.conf file probably has an includedir 
> directive that is /etc/xinetd.d. And restart xinetd.
> 
The product is called FDR/UPSTREAM (http://www.fdr.com/ups.cfm).  Unfortunately, the manuals aren't
online, but it is basically a client/server type of backup software.  A central server and each
machines daemon work together to backup the machine to a central tape library.

The central server runs under IBM's z/OS mainframe OS and, in the case, the machines to be backed up
are running under Linux for S/390.

Unfortunately, it seems that the software doesn't support running from xinetd/inetd.  It wants to be
its own daemon and control its own ports.  Here's the xinetd.conf file I've set up for it: (it uses
port 1972 by default, so I just used the name from /etc/services)

service intersys-cache
{
    socket_type = stream
    protocol    = tcp
    wait        = no
    user        = root
    group       = root
    server      = /opt/fdrupstream/usd
    disable     = no
}

When the central server attempts to connect I receive messages similar to this from the client:

Tue Sep 30 21:06:03 2003 User: root, Group: root, PID: 32549
   Msg #PC1275I Entering UPSTREAM v3.2.1c (Linux S390)
   Config file: /opt/fdrupstream/upstream.cfg
   Work path  : /opt/fdrupstream
   Using TCP/IP, in port: 1972, out port: 1972
Tue Sep 30 21:06:03 2003 User: root, Group: root, PID: 32549
   Msg #PC4825I (TCP/IP) Port number already in use
        Usually caused by another copy of UPSTREAM actively
        listening on the inbound TCP/IP port.
   Msg #PC4765E (TCP/IP) bind failed
        The bind call (which is used to begin
        communications for remote initiates) failed.
        This usually occurs when another copy of UPSTREAM
        has already bound to the inbound TCP port.
        This message can be ignored unless you need to
        service remote requests.

There are no options for the daemon that tell him to use the already established connection near as
I can tell.  It just isn't "super-server" friendly.  I've got a support call into the vendor as
well.  I was just hoping to figure it out this evening.

Thanks much,

Leland