нужно - узнавать собственный pid и перводить себя в bg
я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg
и беред его pid с помощю fork() есть-ли решение лучше?спасибо всем, кто откликнется
getpid() не поможет?
>нужно - узнавать собственный pid и перводить себя в bg
>я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg
>
>и беред его pid с помощю fork() есть-ли решение лучше?
>
>спасибо всем, кто откликнетсяman getpid
man daemon
Скажите пожалуйста, какие Вы нашли статьи по написанию демона и его правильных настройках?
Заранее спасибо.
не тратьте время на создание демонов.
больше выгод можно получить, если написать простое приложение и запускать его из-под daemontools (http://cr.yp.to/daemontools.html), или другого подобного супер-демона.
Зачем так мудрить?
Делается просто:
...
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;
}
...
зачем каждый раз придумывать то, что можно раз и навсегда вынести в отдельную программу?
кроме того, если это демон, придётся решать сопутствующие вопросы:
1) управление демоном (посылка сигналов). в обычной жизни делаем ps -ax|grep <daemonname>; kill -SIGNAl PID. daemontools позволяет посылать сигналы по имени.
2) рестарт демона, если он упал. daemontools делает это автоматически.
3) ведение логов -- придётся писать код и для этого.
или просто бросать логи в свой STDOUT, и подбирать их входящими в состав daemontools средствами.daemontools позволят написать обычное приложение (что значительно проще, а значит и надёжнее), кот. запускается и работает в foreground, не уходя с терминала, и просто пишет логи в STDOUT.
всё остальное -- забота пакета.то-же, в принципе, касается и обработки сетевых соединений. зачем каждый раз в программу встраивать блок для работы с сокетами, если можно вынести это всё в отдельную программу, кот. будет принимать коннекты, проверять все необходимые условия, и потом запускать Вашу программу, перенаправляя ей на STDIN входной поток и выбрасывая наружу, то, что программа пишет в STDOUT.
понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете всё самостоятельно.
но для большинства случаев, как правило, этого вполне достаточно.
>понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете
>всё самостоятельно.
>но для большинства случаев, как правило, этого вполне достаточно.а большинство случаев - это когда ? можно пример пожалуйста.
// wbr
qmail, например, полностью написан, исходя из таких соображений.
всё, что запускается из под inetd, xinted (таких примеров достаточно, взять любой дистрибутив и посмотреть, что там стоит по умолчанию).
>qmail, например, полностью написан, исходя из таких соображенийqmail требует наличия в системе установленных deamontools ?
>всё, что запускается из под inetd, xinted (таких примеров достаточно, взять любой дистрибутив и посмотреть, что там стоит по умолчанию).
-> зачем вам daemontools ? *inetd и вперед и с песнею. хотя *inetd конечно же работает только в случае сетевых сервисов, что изрядно ограничивает область его применения.
man daemon()
man pidfile()
man signal -> SIGHUPвполне хватает для "демона". хотя первые два вызова и не являются стандартом -> ограничение в переносимости.
// wbr
>qmail требует наличия в системе установленных deamontools ?
нет, он может работать и по-другому, но он так задумывался и это его "штатное" применение, точно так-же как и tcpserver.все эти пакеты: qmail, daemiontools, uscpi-tcp, djbdns - произведения одного автора D.J.Bernstein-а, и разрабатывалсь как целый комплекс, а не независимые задачи. хотя их можно использовать и независимо.
>1) управление демоном (посылка сигналов). в обычной жизни делаем ps -ax|grep <daemonname>; kill -SIGNAl PID. daemontools позволяет посылать сигналы по имени.
killall <demonname>
>2) рестарт демона, если он упал. daemontools делает это автоматически.
ууу... если это сложно, то....
>3) ведение логов -- придётся писать код и для этого.
>или просто бросать логи в свой STDOUT, и подбирать их входящими в
>состав daemontools средствами.
>daemontools позволят написать обычное приложение (что значительно проще, а значит и надёжнее),
>кот. запускается и работает в foreground, не уходя с терминала, и
>просто пишет логи в STDOUT.
>всё остальное -- забота пакета.
Аж поперхнулся..... А SysLog зачем если не для логов?>
>то-же, в принципе, касается и обработки сетевых соединений. зачем каждый раз в
>программу встраивать блок для работы с сокетами, если можно вынести это
>всё в отдельную программу, кот. будет принимать коннекты, проверять все необходимые
>условия, и потом запускать Вашу программу, перенаправляя ей на STDIN входной
>поток и выбрасывая наружу, то, что программа пишет в STDOUT.
>
>понятно, что есть исключения, когда Вас что-то не устраивает и Вы пишете
>всё самостоятельно.
>но для большинства случаев, как правило, этого вполне достаточно.
>Аж поперхнулся..... А SysLog зачем если не для логов?
дело вкуса.
я говорю о философии/архитектуре.
это - одна из базовых идей, вокруг которых был когда-то построен UNIX,
идея программ-фильтров. каждая программа выполняет только узкий круг задач, получая что-то через STDIN (условно), выполняя какие-то преобразования, и выбрасывая что-то в STDOUT (опять условно).
это позволяет собирать такие программы в цепочки, что например, вовсю используется в shell.такой подход, м.б. не позволяет получать макс. скорость, но зато позволяет писать простые(надёжные) программы.
"...кому нужна быстрая программа, кот. некорректно работает..."
(дословно не помню, это цитата из книжки Б. Кернигана и Р. Пайка "Практика программирования", из главы об оптимизации программ).я не утверждаю, что всё это необходимо делать, или что это единствено верный путь, это всё моё личное мнение.
я написал это для того, что-бы кто-то мог это использовать (кто захочет).
я эти вещи использую и в своих программах и для управления чужими программами (напр. на моих серверах все демоны запускаются из-под daemontools, даже если они не используют все его возможности).
изначально был написан "демон" под "супер-сервер" из пакета ucspi-tcp
чего не хватет:
1. супер-сервер завершал приложения при дисконнекте
2. нужно общение между просессами, обрабатывающими разние коннекты и единое управление на основе данных, полученних от кадого процесса/цепочки
3. елементарное уравление: HUP, TERM
4. слушать несколько портов, в том числе и uinx-socket(а если-бы есщё и вминяемую книжечку найти по этому делу :))
>>Аж поперхнулся..... А SysLog зачем если не для логов?
>дело вкуса.
>я говорю о философии/архитектуре.
>это - одна из базовых идей, вокруг которых был когда-то построен UNIX,
>
>идея программ-фильтров. каждая программа выполняет только узкий круг задач, получая что-то через
>STDIN (условно), выполняя какие-то преобразования, и выбрасывая что-то в STDOUT (опять
>условно).
>это позволяет собирать такие программы в цепочки, что например, вовсю используется в
>shell.
Дело в том, что демон не может иметь управляющего терминала(если он настоящий демон), то есть понятия stdin и stdout для него ни чего не должны значить, более того: чтобы не было проблем с монтированными системами, он не всегда может взять и записать данные в файл...
>нужно - узнавать собственный pid и перводить себя в bg
>я нашел только такой выход: отдельный скрипт запускает свам "демон" в bg
>
>и беред его pid с помощю fork() есть-ли решение лучше?
>
>спасибо всем, кто откликнетсячитайте
http://docs.flightmedia.ru/unix/unix-faqs/programming-FAQ/fa...
ссылку "1.7 How do I get my program to act like a daemon?"WBR, Dvorkin