LINUX.ORG.RU
ФорумAdmin

xinetd ->создание кучи процессов на 1 пакет


0

0

Проблема.

Есть небольшая программа, принимающия по UDP пакет с даннымы, обрабатывающая их и отсылающая ответ на news сервер.

Программа стартует из под xinetd:

service programm { socket_type = dgram protocol = udp wait = no user = root server = /usr/local/prog/client disable = no port = 22222 }

сама программа выглялит так (конечно, исходная программа больше, но нижеприведенная ведет себя аналогично):

#!/usr/local/bin/perl -w

use News::NNTPClient; use Socket;

my $buff; my @terms; my $news_server_addr="localhost"; my $news_server_port=119;

$server_acc = "1.2.3.4";

my $addr=recv(STDIN,$buff,1536,0); my($port,$IP) = sockaddr_in($addr); #приняли send STDIN, "", 0, sockaddr_in($port,inet_aton($server_acc)); #подтвердили прием

if ( defined ($buff)) { @terms=split (",",$buff); @body = ($terms[1],$terms[2]); @header = ("Newsgroups: test.test", "Subject: test1" , "From: tester"); #обработали данные $c = new News::NNTPClient($news_server_addr, $news_server_port); $c->post(@header, "", @body); #отослали на Nntp }

При приеме пакета на UDP 22222, xinetd пораждает иногда до 10 процессов (а иногда всего 1). Естветственно, один из них обрабатывает пакет, а остальные остаются висеть в памяти.

Почему это происходит и как избавится от кучи левых пораждаемых процессов?


Попробуйте поставить "wait=yes" в xinetd.conf.

man inetd.conf:
...
The wait/nowait entry is applicable to datagram sockets only (other sockets should have a ``nowait'' entry in this space). If a datagram server connects to its peer, freeing the socket so inetd can received further messages on the socket, it is said to be a ``multi-threaded'' server, and should use the ``nowait'' entry. For datagram servers which process all incoming datagrams on a socket and eventually time out, the server is said to be ``single-threaded'' and should use a ``wait'' entry.
...

spirit ★★★★★
()

Если я правильно понял, то wait=yes означает ждать окончания завершения текущего процесса.

Но сам процесс выполняется иногда достаточно долгое время (выборка из БД - до 3х минут). Пришедшие в этот период новые пакеты будут потеряны (не обработаны), ведь так?

EightN
() автор топика

> Естветственно, один из них обрабатывает пакет, а остальные остаются висеть в памяти.

Это точно известно, что они только висят и ничего не делают ?
Может они как раз обрабатывают другие пакеты ?

spirit ★★★★★
()

>> Естветственно, один из них обрабатывает пакет, а остальные остаются висеть в памяти. >Это точно известно, что они только висят и ничего не делают ? >Может они как раз обрабатывают другие пакеты ?

Запускал tcpdump и смотрел. Приходит один пакет. xinetd запускает от 1 до 10 процессов. Первый из них обрабатывает полученный пакет. Остальные просто висят.

Вот сейчас уже видно, что не просто висят. Через 3-5 часов каждый их них завершается, приняв в буфер какой то бред (не реальные пакеты, так как новоприходяшие пакеты обрабатываются вновь запущенными копиями программы).

EightN
() автор топика

Хорошо, а нельзя ли сделать такое (хотя бы для эксперимента):
0) поставить wait=yes, тогда xinetd будет ждать завершения процесса;
1) сам процесс (написать небольшую программулину) будет только брать пакет, запускать вашу программку, передавать содержимое пакета ей и сразу завершаться.

Коряво конечно, но другого ничего придумать не смог.
Или у вас есть другое решение ?

P.S. А с глюками в самом xinetd это не может быть связано ?

spirit ★★★★★
()

2spirit:

Видимо так и придется сделать. Но хотелось бы разобраться, откуда берутся столько левых процессов.

xinetd последний поставил, ситуация не изменилась.

Да, тут вот поставил wait=yes (без добавления дополнительных программ), и пока пакеты не теряются: приходит пакет, процесс его обрабатывает. если во время работы процесса приходит другой пакет, новый процесс (для обработки этого пакета) запускается после завершения старого.

Возможно, при увеличении кол-ва запросов к сервису, пакеты будут теряться, я проверю.

EightN
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.