Алгоритм генерации pid

[alibek]

Где бы почитать про сабж? В частности меня интересует, гарантируется ли уникальность PID в течение какого-либо интервала времени?

Допустим я запустил процесс, зафиксировал его pid и периодически проверяю, живой ли этот процесс.

Но не может быть так, что в периоде между проверками мой процесс помрет, и запустится другой процесс, но с таким же pid?

[LostSoul]

Сквозная нумерация , по порядку , по кругу.

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

По крайней мере до ядра 3

 

Windows аналогично

[jffulcrum]

BTW, в Win7 максимальный размер записи HANDLES (откуда берутся и PID) стал DWORD, то есть столкнуться с дублями PID стало практически нереально (практически больше 200 000 я не видел).  В Unix дефолтом максимальный номер 32768 (15 бит), но тоже можно задрать размерность до 22 бит (опять же практически нереально исчерпать на практике) - гуглите pid_max

[MATPOC]

Многие дистрибутивы (или патчи для ядра) борются с предсказанием pid - генерят случайные pid.

[st_re]

гарантия уникальности только в смысле что ОДНОВРЕМЕННО 2-х процессов с одинаковый пид не бывает.  Но после смерти процесса его пид имеет право быть назначен следующему хоть сразу (если цикл дошел). Увеличение kernel.pid_max (kern.pid_max итд) только снижает вероятность такого переиспользования, т.к. увеличивает цикл.  в линуксе на пятом ядре у меня kernel.pid_max = 4194304. Во фре 99999 уже с 8 версии или даже раньше. во фре еще можно сделать kern.randompid > 1 тогда новый пид будет не +1 а +случайное число от 1 до kern.randompid. Для линукса в ядро вроде не принесли такое же, но патчи есть и вроде как есть дистрибутивы с подобной функциональностью...

 

[alibek]

Мне будет достаточно, если в течение какого-то времени (скажем часа) PID гарантированно не повториться.

Но как я понял, такой гарантии не будет, можно только снизить вероятность, увеличив pid_max.

А рандомизация pid эту вероятность скорее даже повысит.

 

Тогда нужно дополнительно проверить, соответствует ли pid искомому процессу.

Разумеется можно проверять имя процесса, но это не гарантия.

Думаю, что комбинацию pid+comm+lstart можно считать уникальной.

[jffulcrum]

@alibek Ну так пусть процесс файлик со своим текущим PID формирует в опред.месте - тогда вы его всегда найдете, как это делают чуть менее, чем все демоны во фряхе.

[alibek]

Так не в файле дело.

Процесс стартует, его идентификатор в pid-файл сохраняется.

А потом процесс вылетает аварийно, а файл остается.

А если потом новый процесс тот же pid получит, как понять, что было аварийное завершение?

Только что сохранять помимо pid еще и дату/время старта процесса.

[st_re]

ну как минимум по имени процесса тоже сверять..

[orlik]

Почему бы не сделать проверку не только по pid , но и по имени процесса ?

[alibek]

Имя — это comm, я его указывал.

Но его недостаточно, поэтому лучше проверять еще и lstart.

[st_re]

открываете лок файл при старте, если лочится - значит процесс жив, если нет, то ой, нету.

[NewUse]

 

да, проблема решается через flock, не надо изобретать велосипед.

[alibek]

Э... Это если процесс свой.

А если чужой и он lock-файлов не держит?

[ixi]

systemd сделает всё за вас (PIDFile=)

[alibek]

Ну, в systemd и pid-файл не нужен, он и так отловит падение процесса, и на это событие можно повесить нужные задания.

У меня сервер без systemd. Да и вообще, интересно автономное решение, академический такой интерес.

[st_re]

1 час назад, alibek сказал:

Э... Это если процесс свой.

А если чужой и он lock-файлов не держит?

Еcли процесс не форкается, то flock есть не только (2) но и (1) (ну или (3)и(8) на более других ОС :) 

man 1 flock

flock [options] <file|directory> <command> [command args]

 

есть pwait

 

Есть так же всякие пускалки типа daemon, daemontools или, как тут уже сказали про, не к ночи будь помянут. systemd, умеет пускать как с пид файлом так и без, как форкающегося так и не форкающегося, как перезапускать, так и запускать чтото третье по факту падения.