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

[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

[theiced.livejournal.com]

очевидно что нету. посему или пидфайл или говно и палки от системд.

[psilogic.livejournal.com]

что есть пидфайл и как он спасет аццов демократии?

[theiced.livejournal.com]

flock + записать пид залочившего в файл. при попытке нового запуска кроме самого пидфайла проверять ещё есть ли такой процесс. можно ещё ему сигналов послать на предмет жив ли он, всё вот это.

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

[psilogic.livejournal.com]

послать сигнал на предмет сдох ли он - вот эта вот идея выглядит очень антересно
а не подскажет ли уважаемый дон, который из сигналов считается "кошерным" для этой цели?
SIGUSR1 с предварительным signal(SIGUSR1, SIG_IGN)?

что я хочу - защиту от одновременного запуска двух instance, которая не требует танцев с бубном, если прога йопнулась или была йопнута через kill -9

[theiced.livejournal.com]

я ж не линуксоид, откуда я помню как это говно внутре в деталях :)

[psilogic.livejournal.com]

ааа...
ну все равно хоть какой-то выход, спасибо! :)

[afa-at-work.livejournal.com]

kill 0 - не?

[psilogic.livejournal.com]

o, yes yes! :)

[afa-at-work.livejournal.com]

ххе
"а руки то помнят!"

[scholarpunk.livejournal.com]

Молиться надо!..

[psilogic.livejournal.com]

тьфубля! :))))

[metaclass.livejournal.com]

Открыть pidfile и сделать ему сразу unlink при старте?

[psilogic.livejournal.com]

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

винды не позволяют удалять открытый файл, никсы - позволяют

[theiced.livejournal.com]

не обращай внимания, метакласс деградирует в текущем круге общения.

[psilogic.livejournal.com]

ты как всегда человеколюбив =)))

[theiced.livejournal.com]

это не я, это реальность такая. к сожалению.

[afa-at-work.livejournal.com]

унлинк кильнет имя. файл на диске еще размещен. но надо ж имя лочить.

[ujo.livejournal.com]

Дык как все

http://stackoverflow.com/questions/5339200/how-to-create-a-single-instance-application-in-c-or-c

#include <sys/file.h>
#include <errno.h>

int pid_file = open("/var/run/whatever.pid", O_CREAT | O_RDWR, 0666);
int rc = flock(pid_file, LOCK_EX | LOCK_NB);
if(rc) {
if(EWOULDBLOCK == errno)
; // another instance is running
}
else {
// this is the first instance
}

[theiced.livejournal.com]

просто flock очевидно не работает. потому что.

[ujo.livejournal.com]

На NFS это всё плохо совсем будет, да - но вообще это считается вроде как достаточным методом.

[theiced.livejournal.com]

к несчастью считается. ну просто пионерская поделка - сколько ты в неё бабла и людей не вбухивай, останется пионерской поделкой.

[psilogic.livejournal.com]

это ты про nfs, про alt-linux или про оба? :)))

[theiced.livejournal.com]

про линупс вообще.

[psilogic.livejournal.com]

такой код не хочет работать на alt-linux с nfs: выглядит так, будто LOCK_NB игнорируется, второй инстанс виснет на системном вызове "futex"

[afa-at-work.livejournal.com]

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

[ujo.livejournal.com]

NFS плохо работает с блокировками. Холмс, но зачем же для локальных процессов делать файл блокировки на NFS? Тем более что есть специальное место /var/lock/subsys.

[psilogic.livejournal.com]

Что значит зачем - у меня выбора нет. Работать должно по возможности везде.

А /var/lock/subsys - он в этом смысле отличается от прочих мест?

[ujo.livejournal.com]

Var lock subsys размещается на локальной (иногда временной) файловой системе, и ограничений нфс не имеет.

А пидфайлы, если это важно, кладут в var run

[psilogic.livejournal.com]

В общем, на другом компе sfdisk показывает тип файл. системы 83 ("Linux") и все равно тот же глюк. В конце-концов прога заработала через пид-файл и signal(pid, 0).

[ujo.livejournal.com]

sfdisk вообще не о том показывает, не надо туда смотреть. Тип файлухи можно увидеть например командой mount без параметров.

[psilogic.livejournal.com]

OK, завтра посмотрю

[psilogic.livejournal.com]

как оказалось, на компе
/ = ext4 (lockf работает)
/tmp = tmpfs (lockf работает)
/home = nfs (lockf не работает)
ну и дело было в /home/xen...

[ujo.livejournal.com]

Ага, ну вот всё и выяснилось. Спасибо, мне было интересно в чём же дело.

[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]

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