Это может быть сложно, потому что вы можете иметь отдельные экземпляры одного и того же процесса, которые живут независимо. Например, серверы, прослушивающие разные порты, или службы, работающие под разными пользователями. Чтобы различать эти экземпляры, необходимо назначить каждому из них уникальный тег. Тэг часто является файлом, но это может быть локальный сокет в абстрактном пространстве имен, порт TCP и т. Д. - подойдет любой уникальный идентификатор. Когда тег является файлом, это может быть обычный файл, содержащий идентификатор процесса (pid-файл), или именованный канал или сокет, который прослушивает файл, и т. Д. В идеале тег является конечной точкой связи, которая позволяет клиентам подключаться к этому процессу.
Каждый из этих различных типов тегов по-разному проверяет, работает ли искомый экземпляр. Например, с локальным файловым сокетом попробуйте подключиться к нему и запустить процесс, если на этом сокете нет процесса, прослушивающего. Если тег является pid-файлом, проверьте, существует ли процесс с этим идентификатором процесса, но имейте в виду, что это хрупкий процесс, поскольку, если процесс завершился, может быть не связанный процесс, который повторно использовал свой идентификатор. Помните, что если два клиента попытаются достичь процесса за короткий промежуток времени, они могут обнаружить, что процесс не существует, и оба попытаются запустить его; должная защита от этого состояния гонки может быть сложно.
Управлять экземплярами легче, когда все они запускаются одним и тем же процессом супервизора, и этот процесс супервизора обнаруживает, когда экземпляры умирают, и реагирует соответствующим образом. Многие сервисные программы мониторинга могут это сделать.
Если программа не отвечает на известной конечной точке связи и не управляется программой супервизора, тегом бедного человека является pidfile: файл, содержащий идентификатор процесса. Когда вы запустите процесс, запишите pid в файл с заранее заданным именем. Когда вам нужно, чтобы процесс существовал, прочитайте pid-файл и посмотрите, есть ли процесс с этим pid. Когда вы завершите процесс, сотрите файл pid. Наиболее существенная проблема с неконтролируемым pid-файлом заключается в том, что если процесс умирает, его pid может быть повторно использован каким-то не связанным процессом. Вы должны по крайней мере проверить имя процесса или исполняемый файл процесса, чтобы убедиться, что вы говорите с правильным процессом. Многие варианты Unix имеют команду pgrep :pgrep SOMENAME
перечисляет процессы, чье имя содержит SOMENAME в качестве подстроки, с дополнительными опциями для ограничения для конкретного пользователя, для запроса точного соответствия, для изменения того, какое из нескольких возможных понятий «имя процесса» используется, и т. д.
ps -ef | grep -v grep | grep "process_name" || run_command_here