Пример демона реагирующего на start stop status

cat /etc/init.d/%название_приличного_демона%, надеюсь, смотрел?

А в линуксе есть какие-то стандарты на эту тему? Вроде же все костыляют как хотят

Уже есть *Зловещий Лёнин смех*

systemd же

Ну вот на примере скрипта для yandex-disk, там для вызова с параметром status просто запускается yandex-disk status, который выводит краткую информацию с работающего в этот момент демона. Это мне не сильно помогло понять как реализовано все в коде.

И каким бы образом сделали бы вы?

Вроде, ТС спрашивает не про systemd и init, а про требуемый правильный интерфейс своего демона-сервера-программы, про принятое поведение демона в системе (логи, перечитывание конфига, реакция на сигналы).

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

Нет же, мне нужно не скрипт запуска демона написать, а самого демона.

Все верно, именно про принятые поведения для написания своего демона српашиваю.

systemd юниты - это не то, это интерфейс, который прячет от (внезапно) systemd способы взаимодействия с каждым конкретным демоном, а ТС, на сколько я понял, хочет примеры реализации этих механизмов в собственно демоне, а не как их завернуть в инит

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

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

Можешь ловить сигналы в демоне, например. USR2 - status, SIGTERM - stop.

У меня нет единственно верного источника. Накопились некие практические правила. Наверно, кто-то посоветуют толковую статью

Типа," использовать SIGHUP для перечитывания конфига", " при SIGTERM попытка побыстрому завершить транзакции, сохраниться и завершиться", «логгинг в stdout (проще всего) или syslog, потом уже в скрипте запуска организуется логгинг под систему», «файловый pipe для управления демоном - можно использовать для status. либо socket, по ситуации.»

Добавлю, что проще всего гуглить не общую инфу («как делать демона»), а конкретно по задачам: «как сделать логгинг», «как сообщать статус демона», «как конфигурировать демон» и все это на english

Значит пойду читать про сокеты и прочее межпроцессное взаимодействие

man signals

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

man start-stop-daemon

/etc/init.d/skeleton смотрел?
хорошая статейка http://habrahabr.ru/post/141003/

man ipc, man dbus /thread.

Обращаться к специалисту пробовал?

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

Обращаться к специалисту пробовал?

Специалист, решающий подобные проблемы, мне тупо не по карману.

«виндузячьи» ini-файлы вызывают у тебя батхёрт?

«виндузячьи» ini-файлы вызывают у тебя батхёрт?

Нет. Они вызывают во мне брезгливость.

это разновидность батхёрта

«виндузячьи» ini-файлы вызывают у тебя батхёрт?

Нет. Они вызывают во мне брезгливость.

это разновидность батхёрта

У вас, вендузятнегов, всё через батт %)

В общем стало все понятно. Контроль запуска буду проводить по семафору, а сообщения о остановке и передачу статуса от демона реализую через очередь сообщений. Спасибо всем кто отписался по делу в тред.

Контроль запуска буду проводить по семафору, а сообщения о остановке и передачу статуса от демона реализую через очередь сообщений.

Конечно, можно и так, но SysV IPC для таких целей не используют (их вообще мало используют).

Контроль запуска буду проводить по семафору

шта? pid-файл чем не угодил?

Да вроде и неплох этот пид файл, но при чтении инфы о ipc семафор мне показался более надежным.

Отвергая предлагай альтернативу, а то кроме флуда от вас еще не было дельных предложений.

Отвергая предлагай альтернативу

Тебе уже всё сказали - сигналы, start-stop-daemon, смотреть скрипты запуска реальных служб. Как ты дошел до идеи использовать SysV IPC - это для меня загадка. Вполне очевидно, что ты с ним не работал раньше.

Чем SysV IPC плох? Судя по мануалам там все прозрачно и легко. И именно очередью проще всего передать небольшую текстовую информацию от демона работающего с отключенными потоками ввода/вывода. Как дошел до идеи? Погугли межпроцессовые взаимодействия - первая же сотня ссылок тебя в них ткнет.

Чем SysV IPC плох?

Кроме того, что избыточен для озвученной задачи? Неудобной работой с пространством имен и тем, что жизненный цикл объектов не привязан к жизненному циклу процесса.

Судя по мануалам там все прозрачно и легко

А весь мир - идиоты, потому что пользуются pid-файлами и сигналами.

И именно очередью проще всего передать небольшую текстовую информацию от демона работающего с отключенными потоками ввода/вывода

Правда? Не через FIFO, а именно через очередь сообщений? Ооокей.

Погугли межпроцессовые взаимодействия

/me .oO( почему половина тех, кто может вбить в гугл запрос, считают себя такими же умными, как сам гугл? )

Специалист, решающий подобные проблемы, мне тупо не по карману.

Улыбнуло, спасибо.

А весь мир - идиоты, потому что пользуются pid-файлами и сигналами.

У меня было несколько раз при жестком отключении: squid оставлял pid-файл, а при загрузке если другой процесс подхватывал сей pid - то не запускался, если нет - все норм.

Можно придумать случай без перезагрузки, и даже с проверкой процесса (если два демона). Вопрос: почему, скажем, обычно не используют flock/fcntl на pid-файл?

А весь мир - идиоты, потому что пользуются pid-файлами и сигналами.

Аргумент уровня детсада.

А весь мир - идиоты, потому что пользуются pid-файлами и сигналами.

Аргумент уровня детсада.

okay.jpg

У меня было несколько раз при жестком отключении: squid оставлял pid-файл, а при загрузке если другой процесс подхватывал сей pid - то не запускался, если нет - все норм.

Отключении питания? Странно, потому что /var/run чистится довольно рано при раскрутке системы.

почему, скажем, обычно не используют flock/fcntl на pid-файл?

Зачем? От путаницы в случае внезапной смерти демона это не спасет, а если завершение штатное, демон сам удалит свой pid-файл (или инитскрипт сделает это за него).

Я просто сигналы посылаю. Если что-то посложней нужно, использую IPC вроде очередей, или mmap в разделяемой памяти, или еще какую фигню.

Для однозначной гарантии уникальности использую pid-файл + поиск по дереву proc одноименных процессов (если pid-файл показывает, что таких процессов не запущено). Правда, есть тут косячок-с — чтобы не было race conditions приходится делать flock на pid-файл.

В то время как именованный семафор гарантированно заблокирует запуск второго демона. Для меня сейчас очевидно что это лучший из предложенных в треде способов. Тем более что остальные средства SysV IPC (очереди вы указали) вы уже используете и они у вас успешно работают.

именованный семафор

Это какой-то жуткий велосипед, в данном случае не нужный. Все элегантно решается при помощи flock на псевдофайл в shm, то бишь мьютексом.

// семафоры я вообще ни разу не использовал — оверхед же!

Ой вей. Ну я все же не угомонюсь пока вы не объясните почему это жуткий велосипед. Семафор три строчки кода (с обработкой ошибок аж целых 9), которые гарантированно блокируют повторный запуск демона. Без единого слабого места. Почему это плохо?

Семафор три строчки кода (с обработкой ошибок аж целых 9), которые гарантированно блокируют повторный запуск демона. Без единого слабого места.

Опубликуй эти 9 строчек.

Это примерно как использовать printf в микроконтроллерах: можно, но не стоит.