Послание линуксоидам

[psilogic]

А вот просветите прожженного вындузоида насчет одной вещи.

Есть ли в линухе хоть какой-нибудь ресурс, который саморазлочивается при грубом убийстве программы? Хочется сделать защиту от одновременного запуска двух instance. Перепробовал уже open(O_EXCL), flock, lockf, shm_open(O_EXCL), sem_open(O_EXCL), sem_trywait - всё либо жидко срёт на локи, либо виснет (lockf(...F_TEST...)), так как, видите ли, файловая система недоразвитая (nfs), либо в случае убиения через kill -9 оставляет ресурс в состоянии, неотличимом от залоченного.

Щито делать? Неужели уних в этом отношении дохлее выньды?

З.Ы. Есть, конечно, сокеты, но это значит юзать "магический номер" порта, что, мягко гойворя, не приветствуется корпоративными традициями кодопейсательства...

З.Ы.Ы. Спасибо всем за мозговой штурм, в конце-концов все заработало по принципу:
1) проверяем, есть ли нужный файл /tmp/чтототам.pid, читаем оттуда pid
2) если есть - проверяем запущен ли такой процесс через signal(pid, 0)
3) если запущен - дополнительно проверяем через readlink(..."/proc/<pid>/exe"...), что этот процесс имеет то же имя, что и текущий

З.Ы.Ы.Ы причины, почему блокируется lockf(...F_TEST...) и flock(...|LOCK_NB...) так и остались невыясненными: блокируется оно даже и не на nfs

Comments

[afa-at-work.livejournal.com]

unix socket?

[psilogic.livejournal.com]

Разве что в никсах существуют именованные сокеты, иначе придется занимать "well-known" порт, который может внезапно оказаться занят кем-то еще. А то и несколько сокетов, если я хочу иметь представление о состоянии нескольких "наших" процессов. Пока лучшей выглядит идея с созданием файла на старте, удалением на выходе и дополнительной проверкой через посылку signal-а, чтобы исключить краш/килл.

[afa-at-work.livejournal.com]

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

[psilogic.livejournal.com]

А, вот оно что - unix socket ≠ socket in unix :) Учитывая, что интерфейс к сокетам сам по себе довольно инопланетный, наверное, через pid и впрямь дешевле будет.

[afa-at-work.livejournal.com]

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

[russhatter.livejournal.com]

Не очень понятно, почему он "инопланетный". Он просто с древних времён остался, и, поскольку оказался достаточно хорошим, его и не причёсывали с тех времён. Как раз очень хорошая рекомендация. Всем хватает - Вам нет.
Открыть именованный сокет - самое правильное решение. А писать код с нуля - вовсе не обязательно. Простенький код для сервера доступен в более или любом фреймворке.

[psilogic.livejournal.com]

Инопланетный потому, что больше нигде вы не найдете последовательностей инициализации типа socket->bind->listen->accept

[russhatter.livejournal.com]

Ну я и говорю: это давно придумали, слишком давно. Но никому особенно не мешает до сих пор. Код на этом уровне пишется один раз, или даже не пишется. Какая разница: инопланетный-планетный, работает и хана.

[ujo.livejournal.com]

Она видимо и есть лучшая, потому что традиционно её используют. Но вот процесс по пид файлу с PID лучше проверять по наличию в таблице процессов и сверять, тот ли это процесс, номер и заместить могут.

[psilogic.livejournal.com]

Это мудрая мысль, тогда вопрос: это надо вывод [ ps -a ] парсить или есть более гуманный путь?

[ujo.livejournal.com]

Если "везде" касалось только линуксов, тогда проверять /proc/pidnumber/args и /proc/pidnumber/exe

[theiced.livejournal.com]

пока очередной поттеринг там что нибудь не сломает, ага.

[ujo.livejournal.com]

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

[theiced.livejournal.com]

с какой одной? малыш, ты там часом не попутал?