форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"проблеммы при создании 'Демона'"
Сообщение от Wizard (??) on 20-Июл-04, 22:42  (MSK)
нужно - узнавать собственный pid и перводить себя в bg я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg и беред его pid с помощю fork() есть-ли решение лучше? спасибо всем, кто откликнется
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "проблеммы при создании 'Демона'"
Сообщение от vnp (??) on 21-Июл-04, 00:59  (MSK)
getpid() не поможет?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "проблеммы при создании 'Демона'"
Сообщение от AnToXa (ok) on 21-Июл-04, 12:40  (MSK)
>нужно - узнавать собственный pid и перводить себя в bg >я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg > >и беред его pid с помощю fork() есть-ли решение лучше? > >спасибо всем, кто откликнется man getpid man daemon
	Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "проблеммы при создании 'Демона'"
Сообщение от bars_ua (ok) on 28-Июл-04, 11:50  (MSK)
Скажите пожалуйста, какие Вы нашли статьи по написанию демона и его правильных настройках? Заранее спасибо.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "проблеммы при создании 'Демона'"
Сообщение от ihor on 28-Июл-04, 12:00  (MSK)
не тратьте время на создание демонов. больше выгод можно получить, если написать простое приложение и запускать его из-под daemontools (http://cr.yp.to/daemontools.html), или другого подобного супер-демона.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "проблеммы при создании 'Демона'"
	Сообщение от Elf (??) on 29-Июл-04, 13:06  (MSK)
	Зачем так мудрить? Делается просто: ... int pid=fork(); switch (pid) {     case 0: chdir("/"); // Потомок, ушедший из терминала             // собственно и есть демон             setsid();             do_your_demon_tasks();             break;     case -1: printf("Unable to fork :-(\n");              break;     default: printf("Demon went to background pid=%i\n",pid);             break; } ...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "проблеммы при создании 'Демона'"
	Сообщение от ihor on 29-Июл-04, 13:30  (MSK)
	зачем каждый раз придумывать то, что можно раз и навсегда вынести в отдельную программу? кроме того, если это демон, придётся решать сопутствующие вопросы: 1) управление демоном (посылка сигналов). в обычной жизни делаем ps -ax|grep <daemonname>; kill -SIGNAl PID. daemontools позволяет посылать сигналы по имени. 2) рестарт демона, если он упал. daemontools делает это автоматически. 3) ведение логов -- придётся писать код и для этого. или просто бросать логи в свой STDOUT, и подбирать их входящими в состав daemontools средствами. daemontools позволят написать обычное приложение (что значительно проще, а значит и надёжнее), кот. запускается и работает в foreground, не уходя с терминала, и просто пишет логи в STDOUT. всё остальное -- забота пакета. то-же, в принципе, касается и обработки сетевых соединений. зачем каждый раз в программу встраивать блок для работы с сокетами, если можно вынести это всё в отдельную программу, кот. будет принимать коннекты, проверять все необходимые условия, и потом запускать Вашу программу, перенаправляя ей на STDIN входной поток и выбрасывая наружу, то, что программа пишет в STDOUT. понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете всё самостоятельно. но для большинства случаев, как правило, этого вполне достаточно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "проблеммы при создании 'Демона'"
	Сообщение от klalafuda on 29-Июл-04, 14:35  (MSK)
	>понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете >всё самостоятельно. >но для большинства случаев, как правило, этого вполне достаточно. а большинство случаев - это когда ? можно пример пожалуйста. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "проблеммы при создании 'Демона'"
	Сообщение от ihor on 29-Июл-04, 14:40  (MSK)
	qmail, например, полностью написан, исходя из таких соображений. всё, что запускается из под inetd, xinted (таких примеров достаточно, взять любой дистрибутив и посмотреть, что там стоит по умолчанию).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "проблеммы при создании 'Демона'"
	Сообщение от klalafuda on 29-Июл-04, 15:58  (MSK)
	>qmail, например, полностью написан, исходя из таких соображений qmail требует наличия в системе установленных deamontools ? >всё, что запускается из под inetd, xinted (таких примеров достаточно, взять любой дистрибутив и посмотреть, что там стоит по умолчанию). -> зачем вам daemontools ? *inetd и вперед и с песнею. хотя *inetd конечно же работает только в случае сетевых сервисов, что изрядно ограничивает область его применения. man daemon() man pidfile() man signal -> SIGHUP вполне хватает для "демона". хотя первые два вызова и не являются стандартом -> ограничение в переносимости. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "проблеммы при создании 'Демона'"
	Сообщение от ihor on 29-Июл-04, 16:12  (MSK)
	>qmail требует наличия в системе установленных deamontools ? нет, он может работать и по-другому, но он так задумывался и это его "штатное" применение, точно так-же как и tcpserver. все эти пакеты: qmail, daemiontools, uscpi-tcp, djbdns - произведения одного автора D.J.Bernstein-а, и разрабатывалсь как целый комплекс, а не независимые задачи. хотя их можно использовать и независимо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "проблеммы при создании 'Демона'"
	Сообщение от Elf (??) on 29-Июл-04, 15:17  (MSK)
	>1) управление демоном (посылка сигналов). в обычной жизни делаем ps -ax|grep <daemonname>; kill -SIGNAl PID. daemontools позволяет посылать сигналы по имени. killall <demonname> >2) рестарт демона, если он упал. daemontools делает это автоматически. ууу... если это сложно, то.... >3) ведение логов -- придётся писать код и для этого. >или просто бросать логи в свой STDOUT, и подбирать их входящими в >состав daemontools средствами. >daemontools позволят написать обычное приложение (что значительно проще, а значит и надёжнее), >кот. запускается и работает в foreground, не уходя с терминала, и >просто пишет логи в STDOUT. >всё остальное -- забота пакета. Аж поперхнулся..... А SysLog зачем если не для логов? > >то-же, в принципе, касается и обработки сетевых соединений. зачем каждый раз в >программу встраивать блок для работы с сокетами, если можно вынести это >всё в отдельную программу, кот. будет принимать коннекты, проверять все необходимые >условия, и потом запускать Вашу программу, перенаправляя ей на STDIN входной >поток и выбрасывая наружу, то, что программа пишет в STDOUT. > >понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете >всё самостоятельно. >но для большинства случаев, как правило, этого вполне достаточно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "проблеммы при создании 'Демона'"
	Сообщение от ihor on 29-Июл-04, 16:02  (MSK)
	>Аж поперхнулся..... А SysLog зачем если не для логов? дело вкуса. я говорю о философии/архитектуре. это - одна из базовых идей, вокруг которых был когда-то построен UNIX, идея программ-фильтров. каждая программа выполняет только узкий круг задач, получая что-то через STDIN (условно), выполняя какие-то преобразования, и выбрасывая что-то в STDOUT (опять условно). это позволяет собирать такие программы в цепочки, что например, вовсю используется в shell. такой подход, м.б. не позволяет получать макс. скорость, но зато позволяет писать простые(надёжные) программы. "...кому нужна быстрая программа, кот. некорректно работает..." (дословно не помню, это цитата из книжки Б. Кернигана и Р. Пайка "Практика программирования", из главы об оптимизации программ). я не утверждаю, что всё это необходимо делать, или что это единствено верный путь, это всё моё личное мнение. я написал это для того, что-бы кто-то мог это использовать (кто захочет). я эти вещи использую и в своих программах и для управления чужими программами (напр. на моих серверах все демоны запускаются из-под daemontools, даже если они не используют все его возможности).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "проблеммы при создании 'Демона'"
	Сообщение от Wizard (??) on 29-Июл-04, 16:15  (MSK)
	изначально был написан "демон" под "супер-сервер" из пакета ucspi-tcp чего не хватет: 1. супер-сервер завершал приложения при дисконнекте 2. нужно общение между просессами, обрабатывающими разние коннекты и единое управление на основе данных, полученних от кадого процесса/цепочки 3. елементарное уравление: HUP, TERM 4. слушать несколько портов, в том числе и uinx-socket (а если-бы есщё и вминяемую книжечку найти по этому делу :))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "проблеммы при создании 'Демона'"
	Сообщение от Elf (??) on 29-Июл-04, 20:41  (MSK)
	>>Аж поперхнулся..... А SysLog зачем если не для логов? >дело вкуса. >я говорю о философии/архитектуре. >это - одна из базовых идей, вокруг которых был когда-то построен UNIX, > >идея программ-фильтров. каждая программа выполняет только узкий круг задач, получая что-то через >STDIN (условно), выполняя какие-то преобразования, и выбрасывая что-то в STDOUT (опять >условно). >это позволяет собирать такие программы в цепочки, что например, вовсю используется в >shell. Дело в том, что демон не может иметь управляющего терминала(если он настоящий демон), то есть понятия stdin и stdout для него ни чего не должны значить, более того: чтобы не было проблем с монтированными системами, он не всегда может взять и записать данные в файл...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

15. "проблеммы при создании 'Демона'"
Сообщение от Dvorkin (??) on 01-Авг-04, 22:55  (MSK)
>нужно - узнавать собственный pid и перводить себя в bg >я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg > >и беред его pid с помощю fork() есть-ли решение лучше? > >спасибо всем, кто откликнется читайте http://docs.flightmedia.ru/unix/unix-faqs/programming-FAQ/faq_toc.html ссылку "1.7 How do I get my program to act like a daemon?" WBR, Dvorkin
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.