Reputation: 21
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
Upvotes: 2
Views: 1879
Reputation: 1935
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.
Upvotes: 2
Reputation: 139
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.
Upvotes: -1