Как заставить Xinetd работать с wait=yes для protocol=tcp

Question

У меня есть служба, которая будет прослушивать порт 8443 после его запуска. У меня есть xinetd, настроенный для запуска моей службы, когда установлено соединение через порт 8443.

Поэтому Xinetd должен запустить мое приложение, а затем разрешить моему приложению обрабатывать любые входящие соединения.

Я получаю повторяющееся "предупреждение: не удается получить адрес клиента: конечная точка транспорта не подключена", а затем Xinetd отключает мою службу на 10 секунд.

Это происходит только тогда, когда я установил wait = yes.

Остановка моего приложения от прослушивания порта 8443 не имеет значения.

Правильно ли я понимаю флаг ожидания xinetd или я что-то не так с конфигурацией xinetd?

Я посмотрел на справочные страницы, wait=yes обычно ассоциируется с UDP, но там ничего не говорит о том, что вы не можете использовать его с TCP.

Я искал на SO, и все, что я нашел, tcp работает с wait=no.

Я получаю следующие ошибки при подключении к 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

Моя конфигурация:

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

Answer 1

Просто если кто-то еще сталкивался с этим, я искал то же самое. Из этого комментария одного из сопровождающих Стив Грабб здесь он говорит

Служба ожидания - это та, которая принимает соединение. telnet не принимает соединение - он ожидает, что соединение будет принято и сокет дублируется на дескрипторы stdin / out.

Xinetd также не может проверить, принял ли ребенок соединение. Поэтому, когда у вас есть программа, настроенная как служба ожидания, и она не принимает соединение, сокет все еще доступен для чтения, когда xinetd возвращается в цикл выбора. Вокруг и вокруг это идет.

Дочерний сервер запускается с момента, когда xinetd разветвляется, затем вызывает exec_server. когда wait=true, как указано выше, дочерний процесс должен принять соединение через сокет. Для получения сокета файловый дескриптор со значением 0 может быть использован с accept. Я использую Python со следующим,

import socket

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

который возвращает (conn, address), где conn - это новый объект сокета, используемый для отправки и получения данных о соединении.

Answer 2

Из справочных страниц

   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.

Так что если у вас есть ожидание = да, вы однопоточны. Если соединение установлено, ничто другое не может подключиться, пока текущие сеансы не прервутся или сценарий не завершится.