2

I have a service which will listen on port 8443 after it is launched. I have xinetd configured to start my service when a connection is made on port 8443.

So Xinetd should launch my application and then let my application handle any more incoming connections.

I'm getting repeated "warning: can't get client address: Transport endpoint is not connected" and then Xinetd disables my service for 10 seconds.

This only happens when I set wait = yes.

Stopping my application from listening to port 8443 doesn't make a difference.

Is my understanding of xinetd wait flag correct or am I doing something wrong with the xinetd configuration?

I've looked at man pages, wait=yes is usually associated with UDP but nothing in there says you can't use it with TCP.

I searched on SO and everything I found has tcp working with wait=no.

I am getting the following errors when connection to xinetd.

5786]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5786 duration=0(sec)
5564]: START: MyApplication pid=5787 from=<no address>
5787]: warning: can't get client address: Transport endpoint is not connected
5564]: EXIT: MyApplication status=1 pid=5787 duration=0(sec)
5564]: Deactivating service MyApplication due to excessive incoming connections.  Restarting in 10 seconds.
5564]: FAIL: MyApplication connections per second from=<no address>
5564]: Activating service MyApplication

My configuration is:

    disable = no
    socket_type = stream
    protocol        = tcp
    wait            = yes
    user            = user
    server      = /usr/bin/MyApplication
    port            = 8443
    type            = UNLISTED
    flags           = IPv4
Chey
  • 21
  • 3

2 Answers2

2

Just incase anyone else comes across this, I was looking for the same thing. From this comment by one of the maintainers Steve Grubb here, he says

A wait service is one that accepts the connection. telnet does not accept the connection - it expects the connection to be accepted and the socket dup'ed to the stdin/out descriptors.

There is also no way for xinetd to check to see if a child has accepted the connection. Therefore, when you have a program that's configured as a wait service and it doesn't accept the connection, the socket is still readable when xinetd goes back to the select loop. Around and around it goes.

The child server is launched from when xinetd forks then calls exec_server. When wait=true, as mentioend above the child process must accept the connection on the socket. To get the socket the file descriptor with value 0 can be used with accept. I am using python with the following,

import socket

s = socket.fromfd(0, socket.AF_INET, socket.SOCK_STREAM)
print(s.accept())

which returns (conn, address) where conn is a new socket object usable to send and receive data on the connection.

rmawatson
  • 1,909
  • 12
  • 20
-1

From the man pages

   wait             This attribute determines if the service is single-threaded or multi-threaded and whether or not xinetd accepts the connection or the server program accepts  the
                    connection.  If  its  value  is yes, the service is single-threaded; this means that xinetd will start the server and then it will stop handling requests for the
                    service until the server dies and that the server software will accept the connection. If the attribute value is no, the service  is  multi-threaded  and  xinetd
                    will  keep  handling  new  service requests and xinetd will accept the connection. It should be noted that udp/dgram services normally expect the value to be yes
                    since udp is not connection oriented, while tcp/stream servers normally expect the value to be no.

So if you have wait=yes you are single threaded. Once there is a connection nothing else is is able to connect till your current sessions disconnects or the script ends.

Dovid Bender
  • 139
  • 9