LINUX.ORG.RU

Несколько процессов, каждый слушает свой порт


0

1

Привет.
Я тут недавно тему создавал, спрашивал про PID файл PID file
Теперь немного другая ситуация. Есть процесс, который можно запускать несколько раз, передавая ему IP адрес клиента и номер порта. В данном случае пока нет никакой проверки слушается ли данный порт уже или нет. Реализация немного неправильная, потому как неизвестно, сколько процессов потом нужно завершить.

Вопрос, как правильно реализовать работу данного демона?
Мне на ум приходит несколько вариантов.
1. Просто выходить из процесса, если не удаётся открыть уже использующий порт. При этом все процессы завершать с помощью killall (Я так понимаю, самое простое в данной ситуации, но правильное ли?)
2. Создать конфигурационный файл, с перечислением IP адресов и портов и использовать главный процесс как родителя и создавать по процессу на каждый IP.
3. Как-то ещё?

Спасибо.

★★★★★

обычно демоны пытаются открыть сокет, а если это не получается (в т.ч. ии если уже на этом порту кто-то висит) эта копия демона падает, с сообщением в логе «не смогла открыть сокет localhost:666». Как-то так.

Зачем делать killall мне непонятно.

если демон запускает кто-то другой, можно в этом случае выдавать код скажем 77, и этот кто-то другой может попробовать другой порт.

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

drBatty ★★ ()
Ответ на: комментарий от drBatty

Зачем делать killall мне непонятно.

Это был несвязанный поток мыслей, содержащий 2 вопроса ;)
Второй вопрос должен был звучать, как правильно завершить все экземпляры демонов?

UVV ★★★★★ ()
Ответ на: комментарий от tailgunner

Попробую перефразировать.
Сейчас работает так, запускаешь демона - он пытается создать сокет, а потом висит и ждёт коннектов. Демон висит даже в том случае, если сокет открыть не удалось.

Завершать все экземпляры демонов по killall - нормально? (Т.е. можно без PID файла обойтись в принципе?)

UVV ★★★★★ ()
Ответ на: комментарий от UVV

Второй вопрос должен был звучать, как правильно завершить все экземпляры демонов?

ИМХО правильный ответ: как запускал, так и вырубай. Если твой демон сам нафоркал процессов, так пусть он их PIDы хранит, и когда надо вырубает, отсылая им SIGTERM (ну или я не знаю, как тебе лучше, man 5 signal, там по ссылкам и примеры были, да и вообще в гугле много).

drBatty ★★ ()
Ответ на: комментарий от UVV

Т.е. можно без PID файла обойтись в принципе?

в принципе можно, но это не очень-то красиво и Ъ.

drBatty ★★ ()
Ответ на: комментарий от UVV

Демон висит даже в том случае, если сокет открыть не удалось.

O_o

Завершать все экземпляры демонов по killall - нормально?

Если демон пущен как системная служба - нет.

(Т.е. можно без PID файла обойтись в принципе?)

Без pid-файла всегда можно обойтись, проверяя и убивая процессы просто по имени.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Демон висит даже в том случае, если сокет открыть не удалось.

O_o

Это баг, который я правлю. Перед правкой как раз выясняю возможные и правильные пути решения.

UVV ★★★★★ ()
Ответ на: комментарий от tailgunner

Если демон пущен как системная служба - нет.

Можно пояснить, что в данном контексте системная служба?

UVV ★★★★★ ()
Ответ на: комментарий от tailgunner

Фоновый процесс

Фоновый процесс == демон
Автоматически запускаемый == на который есть скрипт в init.d

Чем это отличается от обычного демона?

UVV ★★★★★ ()
Ответ на: комментарий от UVV

Чем это отличается от обычного демона?

«Обычный» демон - это программа, вызвавшая daemon(3). Найти отличия от системной службы - домашнее задание.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

«Обычный» демон - это программа, вызвавшая daemon(3). Найти отличия от системной службы - домашнее задание.

http://man7.org/linux/man-pages/man3/daemon.3.html

The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.

Мы тут поплыли в терминах, по сути daemon(3) - это обёртка над fork(2) и setsid(2). Так ещё раз, что такое системная служба? Или ты про фоновые процессы ядра? Так о них речи не идёт.

UVV ★★★★★ ()
Ответ на: комментарий от UVV

У меня просто напрямую используются fork и setsid.

UVV ★★★★★ ()
Ответ на: комментарий от UVV

Мы тут поплыли в терминах

Не мы.

Так ещё раз, что такое системная служба?

Ты правда ждешь ответа, отличающегося от Несколько процессов, каждый слушает свой порт (комментарий) ?

fork и setsid.

Без chdir, я полагаю?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Мы тут поплыли в терминах

Не мы.

OK, не мы, ты.
Я не вижу разницы между демоном и системной службой, потому что это одно и то же.

Без chdir, я полагаю?

В мане написано

UVV ★★★★★ ()
Ответ на: комментарий от UVV

Мы тут поплыли в терминах

Не мы.

OK, не мы, ты.

Я не вижу разницы между демоном и системной службой, потому что это одно и то же.

Как скажешь %)

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Как скажешь %)

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

UVV ★★★★★ ()
Ответ на: комментарий от UVV

А что подробнее? Первое впечатление, которое получаешь от чтения твоего поста, ты хочешь забацать xinetd.

Возможно я ошибаюсь.

ansky ★★★★★ ()

Завершать процесс по kill приемлемо, если тебя это устаивает, системе это вообще по барабану. Проблема в том, что завершением соединения, закрытием файлов занимается ядро, а не твоя программа. А у тебя могут быть вполне определенные соображения, как тебе нужно завершить соединение (например передать что-нибудь в сокет) или что дописать в файл в конце работы.

В этом случае тоже все просто, перехватываешь в программе обработчик SIGHUP или скажем SIGUSR1 и соответственно прибиваешь процесс не «kill -9», а «kill -SIGHUP». Все получается аккуратно и подконтрольно.

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