проверить процес на сушествование в python

Проверить существование каталога /proc/<pid>

>>> os.getpgid(26625)
7501
>>> os.getpgid(26626)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 3] No such process

Все эти проверки на существование по определению содержат в себе гонку. Кстати, переносимым способом проверки существования процесса является kill(pid, 0), см. man 2 kill.

>Кстати, переносимым способом проверки существования процесса является kill(pid, 0), см. man 2 kill.

Думаешь, os.getpgid есть не во всех юниксах? Если речь про винду, то там os.kill нет.

> Думаешь, os.getpgid есть не во всех юниксах?

Его нет разве что на какой-нибудь древней экзотике. Просто kill(pid, 0) более винтажный :)

> Если речь про винду, то там os.kill нет.

Винда? Что это такое? %)

>переносимым способом проверки существования процесса является kill(pid, 0), см. man 2 kill.

а вдруг процесс есть а послать ему сигнал нельзя? :)

> а вдруг процесс есть а послать ему сигнал нельзя? :)

EPERM

тогда код примерно такой:

try:
   os.kill(pid, signal.SIGKILL)
   print("есть(был) такой pid")
except OSError:
   if errno == os.EPERM:
      print("процесс есть, но не киляется")
   elif errno == os.ESRCH:
      print("может такой pid и был, но щас уже нету")
   else:
      print("есть проблемы({err})".format(err=errno))

> тогда код примерно такой:

Да не в коде дело. Любая проверка существования процесса, с помощью kill или getpgid, изначально racy - к моменту возврата из системного вызова процесс может завершитья.

У kill одно преимущество - там функция проверки и убийства процесса может быть одной и той же (параметризованной номером сигнала).

> print("есть проблемы({err})".format(err=errno))

Бгг, Py3k коде детектед.

так я и не спорю про race condition, в условиях отсутствия блокировок оно всегда так будет когда два процесса независимы.

> Бгг, Py3k коде детектед.

ты не любишь py3k? уже полтора года тока на нём прогаю, он гораздо лучше чем "обычный" питон(кроме скорости :)).

>> Бгг, Py3k коде детектед.

> ты не любишь py3k? уже полтора года тока на нём прогаю

Надеюсь, ты прогаешь исключительно для себя.

> он гораздо лучше чем "обычный" питон(кроме скорости :)).

Мне оттуда хотелось бы получить nonlocal, остальное не нужно, в общем-то.

> Надеюсь, ты прогаешь исключительно для себя.

нет, обычные юзеры уже давно радуются моим скриптам :). Так в чём проблема-то? Ты против питона вообще или считаешь что третья ветка ещё не отлажена?

> Мне оттуда хотелось бы получить nonlocal, остальное не нужно, в общем-то.

Значит у тебя задачи такие. А мне гораздо проще писать на py3k. Хотя бы нет той неразберихи с обычными и юникодными строками, убрали long и соотвественно теперь не поменяется самопроизвольно тип у int когда произойдёт переполнение, модуль multiprocessing(в 2.6 тоже есть), метод format() у строк, итп итп. Короче, py4k будет вообще супер :).

> Так в чём проблема-то? Ты против питона вообще или считаешь что третья ветка ещё не отлажена?

Я считаю, что Питон3 не везде есть. Ну и скорость в реальной жизни тоже лишней не бывает.

>> Мне оттуда хотелось бы получить nonlocal, остальное не нужно, в общем-то.

> Значит у тебя задачи такие.

Это у тебя задачи такие. Как насчет хотя бы PyGtk для Питон3? Numeric? Кучи других библиотек? Может, тебе хватает core Python, но не у всех такие задачи.

> А мне гораздо проще писать на py3k

Не-а, просто тебе лично это больше нравится.

с этой точки зрения py3k не для продакшена. А вот для новых проектов вполне. Либы да, нифига не портированны, пришлось самому недостающие писать. Но попробовав py3k на обычный питон возращаться не хочется совершенно. Я бы сказал этот язык гораздо более "взрослый" без кучи мелких болячек. Надеюсь, py4k будет идеальным :).

"стал идеальным" == "перестал развиваться". Я надеюсь, такого не произойдет никогда :)