shell как правильно определить запущен ли процесс
посмотри в инитскриптах, там обычно бывает такое
просто нужно разбирать вывод ps по колонкам, и сравнивать нужную
но наиболее правильно обходится без такого
просто нужно разбирать вывод ps по колонкам, и сравнивать нужную
но наиболее правильно обходится без такого
ps ax | grep proga -cps ax | grep -v grep | grep proga -c
но наиболее правильно обходится без такого
как? нужно в кроне сделать запуск проги если она не запущена.
к примеру, pptp
да, в данном случае лучше проверять присутствие ppp0
изврат 
> да, в данном случае лучше проверять присутствие ppp0
я бы сделал ip -o route get $PPP_PEER_IP и проверил бы соответствие результата маске
я бы сделал ip -o route get $PPP_PEER_IP и проверил бы соответствие результата маске
По поднятому интерфейсу.
Обычно используют lock-файлы.
---
...Я работаю антинаучным аферистом...
Обычно используют lock-файлы.
---
...Я работаю антинаучным аферистом...
> Обычно используют lock-файлы.
Процесс умрёт, файл удалить забудет.
Процесс умрёт, файл удалить забудет.
а в файл записать пид и потом в проке проверить его наличие 
в рх басед service status так и работает
в рх басед service status так и работает
> а в файл записать пид и потом в проке проверить его наличие
процесс умрёт, файл не удалит, запустится новый с таким же PID-ом
процесс умрёт, файл не удалит, запустится новый с таким же PID-ом
ну опять же в проке можно проверить, что за бинарник запущен с этим пидом
это всё подвержено race condition'ам
в зависимости, конечно, от того, для чего эта информация нужна
пример, если это shutdown script, который намеревается прибить процесс,
то возможна ситуация, когда процесс умирает сам, после проверки, но перед kill
и на его место другой появляется, которого в результате и убивают
когда-то в ru.unix вроде обсуждали это, опытные админы утверждали,
что видели такое дело несколько раз в жизни
в зависимости, конечно, от того, для чего эта информация нужна
пример, если это shutdown script, который намеревается прибить процесс,
то возможна ситуация, когда процесс умирает сам, после проверки, но перед kill
и на его место другой появляется, которого в результате и убивают
когда-то в ru.unix вроде обсуждали это, опытные админы утверждали,
что видели такое дело несколько раз в жизни
ну он-то килять никого не собирается, а для проверки, жива ли прога -- хватит
угу
ещё один неуниверсальный кривой способ
ещё один неуниверсальный кривой способ
а разве pid не уникален в между перезагрузками?
для такого даже 32 бит не хватило бы
а чем он кривой для его задачи? вообще-то start-stop-daemon так и работает.
и какой универсальный? мне, пожалуйста, такой, что бы он и кофе варил еще
и какой универсальный? мне, пожалуйста, такой, что бы он и кофе варил еще
> а чем он кривой для его задачи?
сломается, если нужно будет несколько процессов с одинаковым именем иметь
> вообще-то start-stop-daemon так и работает
так себе работает поэтому
> и какой универсальный?
можно придумать такое
только некому уговаривать авторов всех сервисов его использовать,
несмотря на их религиозные убеждения
сломается, если нужно будет несколько процессов с одинаковым именем иметь
> вообще-то start-stop-daemon так и работает
так себе работает поэтому
> и какой универсальный?
можно придумать такое
только некому уговаривать авторов всех сервисов его использовать,
несмотря на их религиозные убеждения
> сломается, если нужно будет несколько процессов с одинаковым именем иметь
в каком месте?
>можно придумать такое
>только некому уговаривать авторов всех сервисов его использовать,
>несмотря на их религиозные убеждения
было б желание. а уговаривать надо не авторов сервисов, а дистроклепателей, которых меньше
в каком месте?
>можно придумать такое
>только некому уговаривать авторов всех сервисов его использовать,
>несмотря на их религиозные убеждения
было б желание. а уговаривать надо не авторов сервисов, а дистроклепателей, которых меньше
> в каком месте?
если много процессов порождено из одного бинарника, а нам нужно проверить один из них
> а уговаривать надо не авторов сервисов, а дистроклепателей, которых меньше
нужно встраивать это в код каждого сервиса
никакой дистрибутив не сможет поддерживать парралельные ветки для всех пакетов
даже если попытаться, то будут
a) потоки говна со стороны авторов, которым изменения не понравятся
б) потоки вопросов: а почему это в $distribution всё не как у всех, даже $service неправильно запускается?
если много процессов порождено из одного бинарника, а нам нужно проверить один из них
> а уговаривать надо не авторов сервисов, а дистроклепателей, которых меньше
нужно встраивать это в код каждого сервиса
никакой дистрибутив не сможет поддерживать парралельные ветки для всех пакетов
даже если попытаться, то будут
a) потоки говна со стороны авторов, которым изменения не понравятся
б) потоки вопросов: а почему это в $distribution всё не как у всех, даже $service неправильно запускается?
допустим, у тебя рожается один процесс в секунду. ну и как-то они там умирают.
4 млрд (да пусть 2 млрд или 1 млрд - не важно) секунд - это очень много!
это примерно 30 (15, 7.5) лет. ты видел хоть раз систему с аптаймом больше 2 лет?
4 млрд (да пусть 2 млрд или 1 млрд - не важно) секунд - это очень много!
это примерно 30 (15, 7.5) лет. ты видел хоть раз систему с аптаймом больше 2 лет?
> допустим, у тебя рожается один процесс в секунду
допустим, гораздо чаще
допустим, гораздо чаще
>если много процессов порождено из одного бинарника, а нам нужно проверить один из них
запустил прогу -- сложил ее пид в каталог, запустил еще -- положил пид рядышком. если она затрет пид сдохшего экземляра, то и х с ней.
надо проверить по пиду -- нашел в каталоге пид и пошел в прок смотреть, жива ли
надо посмотреть количество -- посмотрел в проке для каждого пида
> нужно встраивать это в код каждого сервиса
зачем? я сам запущу прогу так, как мне нужно и все, что нужно о ней узнаю. и как встраивание кода в прогу поможет узнать, сдохла она или нет?
запустил прогу -- сложил ее пид в каталог, запустил еще -- положил пид рядышком. если она затрет пид сдохшего экземляра, то и х с ней.
надо проверить по пиду -- нашел в каталоге пид и пошел в прок смотреть, жива ли
надо посмотреть количество -- посмотрел в проке для каждого пида
> нужно встраивать это в код каждого сервиса
зачем? я сам запущу прогу так, как мне нужно и все, что нужно о ней узнаю. и как встраивание кода в прогу поможет узнать, сдохла она или нет?
> надо проверить по пиду -- нашел в каталоге пид и пошел в прок смотреть, жива ли
надо проверить не по пиду, а по назначению
например, если несколько pptp до разных мест, и тебя интересует конкретное
pid-файлы помогут слабо
и это если в cmdline видна эта информация, то можно её проверить, и то небезопасно - левый процесс может выставить себе такое название
> я сам запущу прогу так, как мне нужно и все, что нужно о ней узнаю.
не узнаешь:
1) когда запущенный сервис будет готов к работе
пример: для работы хитрого сервиса нужна база mysql, поэтому mysqld нужно
запустить раньше, и дождаться, когда он поднимется и будет готов принимать запросы
2) если программа неожиданно умерла, не узнаешь, если не являешься непосредственным родителем
большинство сервисов делают стандартный detach - соответственно без правки кода проблема нерешаема
3) когда останавливаешь сервис - не узнаешь, когда он полностью остановится, что может
быть важно для того же mysql или например squid, которым нужно много данных сбросить на диск
перед остановом
распространённые методы решения этих задач принципиально ненадёжны, так как содержат
race conditions
надо проверить не по пиду, а по назначению
например, если несколько pptp до разных мест, и тебя интересует конкретное
pid-файлы помогут слабо
и это если в cmdline видна эта информация, то можно её проверить, и то небезопасно - левый процесс может выставить себе такое название
> я сам запущу прогу так, как мне нужно и все, что нужно о ней узнаю.
не узнаешь:
1) когда запущенный сервис будет готов к работе
пример: для работы хитрого сервиса нужна база mysql, поэтому mysqld нужно
запустить раньше, и дождаться, когда он поднимется и будет готов принимать запросы
2) если программа неожиданно умерла, не узнаешь, если не являешься непосредственным родителем
большинство сервисов делают стандартный detach - соответственно без правки кода проблема нерешаема
3) когда останавливаешь сервис - не узнаешь, когда он полностью остановится, что может
быть важно для того же mysql или например squid, которым нужно много данных сбросить на диск
перед остановом
распространённые методы решения этих задач принципиально ненадёжны, так как содержат
race conditions
Оставить комментарий
dgaf
ps ax | grep proga -cмне как-то не нравится. (потому что процесс grep тоже попадает в это условие)
нужно что-н подобное, чтобы было выход 0/1
наверное элементарный вопрос