PID file

Демона в общем случае.

Демон убин kill'om, мои действия?

Вот, кстати, много придумывал: как обезопасить процесс и обеспечить однозначно уникальный запуск. Навелосипедил нечто вроде pgrep + чтение pid-файла. Потом навелосипедил улучшение этого велосипеда (если есть PID-файл, сначала проверяется, что за процесс имеет такой PID: если тот же, то второй процесс отваливается, если чужой — продолжается стандартная проверка по /proc)

Демон убин kill'om

PID-файл стал невалидным. Какие тебе еще нужны действия?

Простейший случай: если нет процесса с PID'ом, записанном в PID-файле, либо этот процесс — не наш, то пересоздать PID файл и работать. Но есть шанс, что у тебя что-то уже работает, а PID-файл кто-нибудь стер, например.

Нажали RESET, твои действия при буте?

Кто должен заботиться о создании и удалении?

О создании — демон. Но путь к PID-файлу задаваться — инитскриптом.

О проверке валидности и удалении — инитскрипт.

OK, т.е. в иделе я так понял - оба.

Если требуется суровая надежность - сделай пару процессов.

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

Проверить наличие PID'а при запуске и решить, что это и нужно ли еще.

Как вариант: создать, открыть, unlink. Тогда файл пропадёт, когда процесс его использующий пропадёт.

Демон убит kill'om, мои действия?

если за создание/УДАЛЕНИЕ pid-файла — отвечает сам демон — то я совершенно не вижу каких-либо препятствий в том чтобы демон мог быть спокойно убит через kill .

главное это чтобы был НЕ ``$ kill -KILL`` (а обычный ``$ kill -TERM``)

когда демон получает системный сигнал о том что его убивают — то демон закрывается и САМ в это время подчищает за собой pid-файл. всё логично :)

http://docs.python.org/3/library/atexit.html#atexit.register

создать, открыть, unlink

Не катит. Файл должен быть видимым.

или может быть надо было дать ссылку эту:

http://docs.python.org/3/library/signal.html#signal.signal

А если его по kill -9 грохнули? Или он сам с сегфолтом каким-нибудь отвалился, либо от oom-killer'а по башке получил?

тогда то что я аписал не поможет :)

вот именно поэтому сейчас и внедряется везде SystemD ...

..а не потомучто Леннарт якобы дружит с гипножабой :-)

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

Свои варианты я выше приводил. Они работают и никаких зондов в задницу вставлять не надо.

да если подумать — то какого фига вообще демон должен заботится о своём собственном PID ?

демон должен просто работать. и уметь себя корректно завершать (когда его просят завершать).

ситуации с segfault — сервершенно не является компетенцией демона, который делает эти segfault . за разрешение таких ситуаций должен отвечать вышестоящщий демон сервис.

это точно также логично, как и логично не обращать внимание на segfault-ные ситуации во время создания/удаления PID силами самого демона.

какого фига вообще демон должен заботится о своём собственном PID?

Ничего себе. Если подумать, какого фига я должен заботиться о своем благосостоянии? Пусть меня озолотят! А я ничего ради этого не буду делать.

ситуации с segfault — сервершенно не является компетенцией демона, который делает эти segfault

Ага, отвалившийся после километра пробега кардан — не вина автомеханика дяди Васи.

Ага, отвалившийся после километра пробега кардан — не вина автомеханика дяди Васи.

а почему это его вина? наиболее вероятно — что был инцедент с неким хулиганом, который проник на автостоянку ОЧЕНЬ СИЛЬНО стучал жёстким диском по кардану...

....(а потом на этом жёстком диске — хулиган установил Linux.. но уже уже другая история :))....

по крайней мере мы знаем что автомеханник приложил все силы чтобы кардан не отваливался :)

(даже если окажется что ситуация с хулиганом оказалась вымышленной кемто :))

вобщем, мне кажется что я НЕ смогу тебе обяснить всю эту ЛеннартПоттерингвскую философию..

..её надо понимать.... чуствовать....

она приходит сама к тебе, если захочет

Для этого надо мастдайку осилить ;)

кстате на МастДайке — SystemD не работает.. и поэтому если нужно запускать демон именно там — то как раз МастДай это именно то место где нужно тра..продумывать ситуации с различными неожиданными завершениями демона (Segfault) и его соответствующим отношением к PID-файлу..

..а вот святой GNU/Linux в лицце Поттеринга — всё упрощает. и делает логичным =(^_^)=

в генточке об этом может позаботиться start-stop-daemon, насчет других дистров не знаю, может он там тоже есть

ТОЧНО! я понял! ДА! нужно осилить весь геморой в венде, чтобы понять почему нужен SystemD

(вендовый геморой — этоже многократно-усиленный геморой старых UNIX-принципов!!!)

венда — она как лупа!

Я как раз с помощью него на убунте тестил, и всплыло вот это http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610719
Поэтому решил узнать как люди делают и предоставить более стабильное решение.

а зачем в винде PID-файл нужен-то? Там вроде как винда сама за сервисами следит

венда — она как лупа!

За лупой ☺

святой GNU/Linux в лицце Поттеринга

Фуууу...

Ну ты и вендузятник.

В винде sc есть.

StarCraft ?

yeeeeaaaaaaaaaap!

ну да, есть. А что хотел сказать анонимус - не понятно

Вообще не понимаю зачем нужны эти пиды? Ведь можно же просто сделать один раз символьное устройство которое работало бы по следующему принципу: при чтении из него отдавало количество процессов запущенных от данного бинарника (или скрипта). И при запуске демон должен прочесть из этого устройства цифру, а дальше в зависимости если число равно 1 (т.е. один процесс от этого файла в системе) то начать работу, а если больше то самоубитсама.

ды вы что?! обкурились все?!

для этого дела в операционной системе есть блокировочные файлы!

делаешь при запуске демона — по отношению к блокировочному-файлу (не файлу устройства, а блокировачному файлу!) — ЭКСКЛЮЗИВНУЮ-НЕ_БЛОКИРУЮЩУЮ блокировку...

...и в этом случае второй демон просто не сможет запустится.

что за костыли вы какието предлагаете? демон сам себя убивает если видит своего клона — ДЫ ЭТО ОХРЕНЕТЬ МОЖНО какой костыль!

PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.

PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.

Для того, чтобы скрипты знали PID демона?
А для предотвращения повторного запуска lock-файл, так?

Вот из - за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками

Для того, чтобы скрипты знали PID демона?

ну да...

например если надо какойнить сигнал отправить

хотя да. PID-файл особо то не нужен. например. если есть шина dBus.

А для предотвращения повторного запуска lock-файл, так?

дааа...

заниматься lock-файлом правда не обязан именно самому демону.

за него могут сделать это другие :) ..

например внутри скрипта по запуску:

$ flock -xn /run/my_daemon/lock /usr/bin/my_daemon

ну или вообще использовать SystemD и не париться об блокировачных файлах тогда

Гейтс, залогинся уже! Мы тебя раскусили :)

Вот из - за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками

ты двошник! :-)

блокирвачные файлы НЕ НУЖНО СПЕЦИАЛЬНО УДАЛЯТЬ . они могут существовать ВЕЧНО и это никак не мешает запускать программу МНОГО РАЗ ПОВТОРНО...

...проверь сам:

$ flock -xn ~/my_test_lock_file /usr/bin/gedit

(не удаляя файл ~/my_test_lock_file — попробуй много раз подрят позапускай эту строчку...)

# P.S.: вы меня троллите чтоле? я не пойму?

Тут один тролль в треде сделал логичный коммент, а если демон упал, а файл остался. Проверять скриптом, есть ли всё ещё демон?

Забей на него, он тролль =)
Так что, мы пришли к тому, что файлы копятся? Как они потом удаляются?

Гейтс, залогинся уже! Мы тебя раскусили :)

если бы я был бы Гейстчом — ябы начал рассказывать что Венде для блокировачных файлов — существует специальная (сугубо виртуальная) файловая система..

...и называются они не «блокировачные файлы» а «именованные мьютексы» :)

ан нет! я всего лишь вам рассказывают про блокировачные файлы внутри сугубо-физической файловой системе /run/ . и не разу не произнёс слово «мьютекс» (хотя по смыслу это оно и есть, но только внутри файловой системы) .

в генточке об этом может позаботиться start-stop-daemon, насчет других дистров не знаю, может он там тоже есть

Как часть openrc, эту тулзень можно скомпилять подо что угодно. Да и другие варианты есть. В большинстве случаев своё приложение можно даже не учить демонизироваться и делать всякие сопутствующие церемонии, а выполнять это всё start-stop-daemon'ом или аналогом.

всплыло вот это http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610719

Так это не баг, там костыль предложен для неправильного использования. Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон, тогда и с пидфайлом никаких проблем не будет.

Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон..

Давно это?

Если уж доверяешь дело сторонней тулзе, то доверяй целиком. Не доверяешь — велосипедь всё сам. Да и проще так со всех сторон.

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

Создавай unix-сокет или обычный файл с O_CREAT | O_EXCL (man 2 open).