![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Послание линуксоидам
А вот просветите прожженного вындузоида насчет одной вещи.
Есть ли в линухе хоть какой-нибудь ресурс, который саморазлочивается при грубом убийстве программы? Хочется сделать защиту от одновременного запуска двух 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
Есть ли в линухе хоть какой-нибудь ресурс, который саморазлочивается при грубом убийстве программы? Хочется сделать защиту от одновременного запуска двух 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
no subject
no subject
no subject
непонятно что ты хочешь сделать вообще говоря, но тебе надо взять любого линупсового демона, посмотреть чего у него внутре и делать так же.
no subject
а не подскажет ли уважаемый дон, который из сигналов считается "кошерным" для этой цели?
SIGUSR1 с предварительным signal(SIGUSR1, SIG_IGN)?
что я хочу - защиту от одновременного запуска двух instance, которая не требует танцев с бубном, если прога йопнулась или была йопнута через kill -9
no subject
no subject
ну все равно хоть какой-то выход, спасибо! :)
no subject
no subject
no subject
no subject
винды не позволяют удалять открытый файл, никсы - позволяют
no subject
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
}
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
"а руки то помнят!"
no subject
no subject
no subject
no subject
no subject
no subject
NFS плохо работает с блокировками. Холмс, но зачем же для локальных процессов делать файл блокировки на NFS? Тем более что есть специальное место /var/lock/subsys.
no subject
Она видимо и есть лучшая, потому что традиционно её используют. Но вот процесс по пид файлу с PID лучше проверять по наличию в таблице процессов и сверять, тот ли это процесс, номер и заместить могут.
no subject
no subject
no subject
А /var/lock/subsys - он в этом смысле отличается от прочих мест?
no subject
no subject
Открыть именованный сокет - самое правильное решение. А писать код с нуля - вовсе не обязательно. Простенький код для сервера доступен в более или любом фреймворке.
no subject
no subject
Если "везде" касалось только линуксов, тогда проверять /proc/pidnumber/args и /proc/pidnumber/exe
no subject
Var lock subsys размещается на локальной (иногда временной) файловой системе, и ограничений нфс не имеет.
А пидфайлы, если это важно, кладут в var run
no subject
no subject
no subject
no subject
Сильно у вас бомбит. Впрочем, сочувствую опыту работы с только одной системой.
no subject
sfdisk вообще не о том показывает, не надо туда смотреть. Тип файлухи можно увидеть например командой mount без параметров.
no subject
no subject
no subject
/ = ext4 (lockf работает)
/tmp = tmpfs (lockf работает)
/home = nfs (lockf не работает)
ну и дело было в /home/xen...
no subject