Для чего нужны файлы pid и lock?
Я часто вижу, что программы указывают файлы pid и lock. И я не совсем уверен, что они делают.
Например, при компиляции nginx:
Может кто-нибудь пролить свет на этот?
pid-файлы пишутся некоторыми программами для записи их идентификатора процесса во время их запуска. Это имеет несколько целей:
- Это сигнал другим процессам и пользователям системы, что эта конкретная программа запущена или, по крайней мере, успешно запущена.
- Это позволяет очень легко написать скрипт, проверить, работает ли он, и выполнить простую kill команду, если кто-то хочет завершить его.
- Для программы это дешевый способ узнать, не был ли предыдущий запущенный экземпляр успешно завершен.
Разумеется, наличие pid-файла не гарантирует, что этот конкретный идентификатор процесса работает, поэтому этот метод не на 100% надежен, но во многих случаях «достаточно хорош». Проверка наличия определенного PID в таблице процессов не является полностью переносимой в UNIX-подобных операционных системах, если только вы не хотите зависеть от ps утилиты, которую может быть нежелательно вызывать во всех случаях (и я считаю, что некоторые UNIX-подобные операционные системы В ps любом случае реализовать по- другому).
Файлы блокировки используются программами для обеспечения того, чтобы два (с хорошим поведением) отдельных экземпляра программы, которые могут одновременно работать в одной системе, не обращались к чему-то другому одновременно. Идея состоит в том, что прежде чем программа получит доступ к своему ресурсу, она проверяет наличие файла блокировки, и, если файл блокировки существует, либо выдает ошибку, либо подождите, пока она не исчезнет. Когда он не существует, программа, желающая «приобрести» ресурс, создает файл, а затем другие экземпляры, которые могут встретиться позже, будут ожидать завершения этого процесса. Конечно, это предполагает, что программа, «получающая» блокировку, фактически снимает ее и не забывает удалить файл блокировки.
Это работает, потому что файловая система во всех UNIX-подобных операционных системах обеспечивает сериализацию , что означает, что в любой момент времени происходит только одно изменение файловой системы. Вроде как блокировки с базами данных и тому подобное.
Источник
PID file
Задача демона или init script’a?
Кто должен заботиться о создании и удалении?
Демона в общем случае.
Демон убин kill’om, мои действия?
Вот, кстати, много придумывал: как обезопасить процесс и обеспечить однозначно уникальный запуск. Навелосипедил нечто вроде pgrep + чтение pid-файла. Потом навелосипедил улучшение этого велосипеда (если есть PID-файл, сначала проверяется, что за процесс имеет такой PID: если тот же, то второй процесс отваливается, если чужой — продолжается стандартная проверка по /proc)
PID-файл стал невалидным. Какие тебе еще нужны действия?
Простейший случай: если нет процесса с PID’ом, записанном в PID-файле, либо этот процесс — не наш, то пересоздать PID файл и работать. Но есть шанс, что у тебя что-то уже работает, а PID-файл кто-нибудь стер, например.
Нажали RESET, твои действия при буте?
Кто должен заботиться о создании и удалении?
О создании — демон. Но путь к PID-файлу задаваться — инитскриптом.
О проверке валидности и удалении — инитскрипт.
OK, т.е. в иделе я так понял — оба.
Если требуется суровая надежность — сделай пару процессов.
Не, требуется просто проконтроллировать, чтобы демон был только один. Есть другие методы?
Проверить наличие PID’а при запуске и решить, что это и нужно ли еще.
Как вариант: создать, открыть, unlink. Тогда файл пропадёт, когда процесс его использующий пропадёт.
если за создание/УДАЛЕНИЕ pid-файла — отвечает сам демон — то я совершенно не вижу каких-либо препятствий в том чтобы демон мог быть спокойно убит через kill .
главное это чтобы был НЕ «$ kill -KILL« (а обычный «$ kill -TERM«)
когда демон получает системный сигнал о том что его убивают — то демон закрывается и САМ в это время подчищает за собой pid-файл. всё логично 🙂
Не катит. Файл должен быть видимым.
или может быть надо было дать ссылку эту:
А если его по 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 есть.
ну да, есть. А что хотел сказать анонимус — не понятно
Вообще не понимаю зачем нужны эти пиды? Ведь можно же просто сделать один раз символьное устройство которое работало бы по следующему принципу: при чтении из него отдавало количество процессов запущенных от данного бинарника (или скрипта). И при запуске демон должен прочесть из этого устройства цифру, а дальше в зависимости если число равно 1 (т.е. один процесс от этого файла в системе) то начать работу, а если больше то самоубитсама.
ды вы что?! обкурились все?!
для этого дела в операционной системе есть блокировочные файлы!
делаешь при запуске демона — по отношению к блокировочному-файлу (не файлу устройства, а блокировачному файлу!) — ЭКСКЛЮЗИВНУЮ-НЕ_БЛОКИРУЮЩУЮ блокировку.
. и в этом случае второй демон просто не сможет запустится.
что за костыли вы какието предлагаете? демон сам себя убивает если видит своего клона — ДЫ ЭТО ОХРЕНЕТЬ МОЖНО какой костыль!
PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.
PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.
Для того, чтобы скрипты знали PID демона?
А для предотвращения повторного запуска lock-файл, так?
Вот из — за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками
Для того, чтобы скрипты знали PID демона?
например если надо какойнить сигнал отправить
хотя да. PID-файл особо то не нужен. например. если есть шина dBus.
А для предотвращения повторного запуска lock-файл, так?
заниматься lock-файлом правда не обязан именно самому демону.
за него могут сделать это другие 🙂 ..
например внутри скрипта по запуску:
$ flock -xn /run/my_daemon/lock /usr/bin/my_daemon
ну или вообще использовать SystemD и не париться об блокировачных файлах тогда
Гейтс, залогинся уже! Мы тебя раскусили 🙂
Вот из — за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками
блокирвачные файлы НЕ НУЖНО СПЕЦИАЛЬНО УДАЛЯТЬ . они могут существовать ВЕЧНО и это никак не мешает запускать программу МНОГО РАЗ ПОВТОРНО.
/my_test_lock_file — попробуй много раз подрят позапускай эту строчку. )
# P.S.: вы меня троллите чтоле? я не пойму?
Тут один тролль в треде сделал логичный коммент, а если демон упал, а файл остался. Проверять скриптом, есть ли всё ещё демон?
Забей на него, он тролль =)
Так что, мы пришли к тому, что файлы копятся? Как они потом удаляются?
Гейтс, залогинся уже! Мы тебя раскусили 🙂
если бы я был бы Гейстчом — ябы начал рассказывать что Венде для блокировачных файлов — существует специальная (сугубо виртуальная) файловая система..
. и называются они не «блокировачные файлы» а «именованные мьютексы» 🙂
ан нет! я всего лишь вам рассказывают про блокировачные файлы внутри сугубо-физической файловой системе /run/ . и не разу не произнёс слово «мьютекс» (хотя по смыслу это оно и есть, но только внутри файловой системы) .
в генточке об этом может позаботиться start-stop-daemon, насчет других дистров не знаю, может он там тоже есть
Как часть openrc, эту тулзень можно скомпилять подо что угодно. Да и другие варианты есть. В большинстве случаев своё приложение можно даже не учить демонизироваться и делать всякие сопутствующие церемонии, а выполнять это всё start-stop-daemon’ом или аналогом.
Так это не баг, там костыль предложен для неправильного использования. Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон, тогда и с пидфайлом никаких проблем не будет.
Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон..
Если уж доверяешь дело сторонней тулзе, то доверяй целиком. Не доверяешь — велосипедь всё сам. Да и проще так со всех сторон.
Не, требуется просто проконтроллировать, чтобы демон был только один. Есть другие методы?
Создавай unix-сокет или обычный файл с O_CREAT | O_EXCL (man 2 open).
Источник
