Как бы вы сделали проверку на запуск второго экземпляра программы?

Question

[memba]

Нужно организовать простую проверку на запуск второго экземпляра программы и по возможности заблокировать его.

Первое:
Я бы создал PID файл и вешал на него исключительную блокировку. Соответственно, если файл заблокирован, то приложение уже запущенно. Проблема: как я вижу в Go не реализован кроссплатформенный способ блокировки файла из коробки (syscall.Flock не поддерживается под Windows), писать костыль не разумно.

Второе:
Я бы установил Мьютекс. Проблема: как я вижу в Go нет поддержки именованных мьютексов и соответственно они доступны только в приделах одного процесса.

Третье:
Я бы занял какой-нибудь порт и при каждом запуске программы проверял его занятость. Проблема: Не очень хорошо забивать порт, темболее он может быть уже занят изначально. И в Go нет простого способа проверить доступность порта. Можно только к нему подключится используя net.Listen("tcp", ":8080"), проверить результат подключения и сразу отключится.

Comments

[Владимир Мартьянов]

Ну в винде это делается через CreateMutex/CreateEvent + GetLastError. Но если язык не дает доступа к WinAPI - печаль...

Answer 1

[Виталий Филинков]

Третий способ самый кошерный и самый универсальный.

Comments

[memba]

Ваше простое утверждение пока лидирует. Мне пришлось реализовать именно этот вариант. Скорее всего это и будет решением.

[Виталий Филинков]

memba: обычно я делаю так: небольшой сервер, который слушает порт. При старте - попытка подключиться к серверу. Если удалось, отправляем команду (это для десктопных приложений) на активацию окна и закрываемся. В противном случае запускаем сервер и слушаем порт. Решение это принесено еще со времен кодинга на С++. Кстати, в QT, если мне не изменяет склероз, QSingleApplication именно так и реализован.

[Oleg Shevelev]

Что если по правилам безопасности приложение нельзя запустить потому что открытие портов не доступно?:)

[Виталий Филинков]

А что, если с неба начнут сыпаться камни? Все "исключительные" ситуации надо рассматривать отдельно.

Answer 2

[Tyranron]

Мне не нравится 3й вариант, так как он не решает задачу целиком. Порт, который слушать - это больше конфигурационный параметр, значит надо задумываться уже, ничего ли страшного не случится при смене порта и рестарте (обычно не должно, но раз на раз не приходится). А что, если демону и вовсе не нужно слушать какой-либо порт? Не универсальненько.

Увы, кросс-платформенного решения "из коробки" нет, да. Я когда стряпал свою поделку, то меня интересовали только *nix-like платформы, мне хватило старого хорошего PID-файла с syscall.Flock. То, что видел в других решениях, более кросс-платформенных, - люди заморачивались на platform specific код, для Windows они использовали регистрацию процесса в виде сервиса. Обернуть это дело в отдельный пакет с единым интерфейсом и platform specific компиляцией совсем не сложно в случае с Go. Для работы с сервисами Windows есть замечательный, пусть и не входящий в стандартную либу, но все же официальный пакет golang.org/x/sys/windows/svc, и костылить на чистых syscall'ах даже не нужно.
Также загляните в этот тред, там как раз про решение для Windows в виде semaphore/mutex аналогично тому, что указал Владимир Мартьянов в комментарии к Вашему вопросу и тому, что Вы указали 2м пунктом.

Answer 3

[index0h]

Пидфайл -> проверка существования процесса по pid -> если уже существует:
* да -> закрыть
* нет -> удалить пидфайл, если есть -> запустить

-----

Есть альтернативный вариант запуска: через supervisor

Comments

[memba]

К сожалению, если программа упала или сервер ресетнулся, файл с пидом останется и пид может быть выдан другому процессу. Я не могу просто так килять процесс, не удостоверившись, что программа действительно запущена.

[index0h]

тогда - supervisor

[Oleg Shevelev]

memba: Проверяйте наличие запущенного приложения идентификатор которого записан в pid файл:) Да и в Linux /etc/init.d/ со start-stop-daemon решают эту проблему классическим способом, в Windows свои сервисы... а универсально - проверять самому (если есть такая возможность).

Answer 4

[Saboteur]

memba:
PID файл не нужно блокировать.
Посмотрите что лежит внутри файлов /var/run
все pid файлы внутри хранят номер процесса. Поэтому файл не нужно блокировать, нужно просто проверять наличие файла, считвыать из него номер процесса и проверять существует ли такой процесс.
Если не существует - значит предыдущее выполнение программы было завершено некорректно.

Файл потому и называется PID, что в нем лежит PID ;)

Comments

[memba]

А я то думаю, что он так называется. Простите.
Я уже указал комментарий ко всем подобным ответ выше.
Если PID файл не заблокирован, то нет уверенности, что приложение сейчас запущено. Представим ситуацию: Сервер ресетнуло. PID файл с идентификатором процесса остался. Сервер запускается, этот идентификатор дается другому процессу. PID есть, процесс есть, приложение не запущено и не будет запущено.
Намного хуже когда нужно убить процесс.

[Saboteur]

memba: Вероятность того, что вы указали настолько низкая, что описанный выше метод используется в продакшене для множества систем.
Если вам мало проверки на существование процесса, можете по указанному PID также получить имя процесса и сверить. Вплоть до командной строки целиком.

Answer 5

[Andrey K]

Можно просто самому проверять PID файл при запуске..

Comments

[memba]

Но он должен быть заблокированным тогда. Только это может означать, что програма запущена, а не упала, не удалив файл.

Answer 6

[RomanPyr]

В Unix можно использовать unix sockets (как это делает ssh-agent), в windows named pipes. Для последнего:
https://github.com/natefinch/npipe