UNIX way
Что такое UNIX way? Я понимаю это как максимально простое из адекватных решений задачи. Попробую лучше раскрыть свою мысль на примере.
Демоны
Итак, в UNIX-е неинтерактивные процессы, запущенные в единственном экземпляре на всю систему называются демонами. Пример демона - сервер базы данных, вебсервер, и тд. Также многие компоненты ОС реализованы не в ядре, а в виде демона, работающего в пользовательском режиме. В MacOS X к примеру используется гибридная система идентификации пользователей: одновременно используются стандартные UNIX-ные идентификаторы пользователя и группы (локально-уникальные целые числа), расширенные идентификаторы пользователя и группы (глобально-уникальные 16 байтные UUID-ы) а также виндовые SID-ы, если компьютер с MacOS подключен к ActiveDirectory. Внутри себя, ядро MacOS X оперирует расширенными идентификаторами пользователя и группы. Кроме того, стандартные UNIX-ные идентификаторы пользователя и группы представлены в BSD-шной подсистеме ядра (этот слой реализует POSIX-совместимый интерфейс системных вызовов). Само по себе, ядро не умеет конвертировать между стандартными и расширенными идентификаторами. Учетом пользователей и групп, а также конвертацией идентификаторов из одного представления в другое заведует демон memberd.
Pid-файлы
Существуют определенные соглашения, которые регламентируют поведение демона. В частности, на старте демон должен создать файл /var/run/<имя-демона>.pid, и записать в него собственный идентификатор процесса. Это действие преследует две цели: во-первых, этот файл помогает всем заинтересованным сторонам найти процесс демона. Во-вторых, если по ошибке был запущен второй экземпляр демона, наличие pid-файла будет сигнализировать что демон уже запущен, следовательно надо предупредить пользователя, и завершить процесс. Тут правда есть одна проблема.
В принципе, демон может внезапно помереть, и не подтереть за собой pid-файл. Чтобы демон не отказался перезапускаться в такой ситуации (pid-файл то есть, значит демон уже запущен?) используют рекомендательные блокировки на файлах. Демон не просто создает pid-файл, он блокирует файл в эксклюзивном режиме (поскольку блокировка рекомендательная, она не препятствует чтению файла другими процессами). Блокировки на файлах автоматически снимаются при завершении процесса (в том числе, аварийном). Если нам встретился незаблокированный pid-файл, мы его просто проигнорируем.
Pid-файлы - хороший пример UNIX way. Во-первых, это решение надежно исключает одновременный запуск нескольких экземпляров демона, и не требует никакой специальной поддержки от ОС. Во-вторых, это не слишком надежный механизм для получения идентификатора процесса демона. Хотя каждая из операций создания/открытия файла, стирания старого содержимого и записи PID-а атомарна, это три отдельные операции, поэтому если не повезет, другие программы могут обнаружить pid-файл в неконсистентном состоянии. Но это небольшая проблема, поскольку демоны стартуют и завершаются сравнительно редко.
Пример анти UNIX-way в этой ситуации - добавляя сложность пытаться починить изначально дырявую абстракцию. Я видел программы, которые получали список активных процессов, чтобы проверить, что за данным pid скрывается именно тот процесс, который они ожидали. Если вам нужен надежный канал для связи с демоном, используйте сокеты.
Running with the least privileges
Есть хороший принцип - наделять демон минимально необходимыми привелегиями. Тогда, когда демон взломают, плохие парни не получат полный контроль над системой. Часто на старте демону нужны привелегии супер-пользователя. Например, чтобы открыть TCP порт ниже 1024-ого или создать файл в /var/run. Хорошая идея после инициализации отказаться от лишних привелегий и из root-а стать (например) nobody. Правда впереди нас ждет одна проблема.
Когда демон будет завершаться, ему потребуется удалить pid-файл. В стандартной UNIX-ной модели прав доступа чтобы удалить файл нужны права записи в объемлющую директорию. Очевидно, у nobody нет прав записи в /var/run. UNIX-way в данной ситуации… просто забить - не удалять файл. Все кто работает с pid-файлами и так готовы к ситуации, когда pid-файл есть, а демона уже нет.
Анти UNIX-way в этой ситуации - извратиться, и как-нибудь добиться удаления pid-файла. Например вспомнить, что помимо стандартной UNIX-ной модели прав доступа, современные системы поддерживают ACL. ACL позволяет дать права на удаление конкретного файла определенному пользователю, не открывая целиком директорию на запись.
Особого смысла я в этом не вижу - в понедельник, придя на работу, вырежу код работающий с ACL-лями из проекта.
Демоны
Итак, в UNIX-е неинтерактивные процессы, запущенные в единственном экземпляре на всю систему называются демонами. Пример демона - сервер базы данных, вебсервер, и тд. Также многие компоненты ОС реализованы не в ядре, а в виде демона, работающего в пользовательском режиме. В MacOS X к примеру используется гибридная система идентификации пользователей: одновременно используются стандартные UNIX-ные идентификаторы пользователя и группы (локально-уникальные целые числа), расширенные идентификаторы пользователя и группы (глобально-уникальные 16 байтные UUID-ы) а также виндовые SID-ы, если компьютер с MacOS подключен к ActiveDirectory. Внутри себя, ядро MacOS X оперирует расширенными идентификаторами пользователя и группы. Кроме того, стандартные UNIX-ные идентификаторы пользователя и группы представлены в BSD-шной подсистеме ядра (этот слой реализует POSIX-совместимый интерфейс системных вызовов). Само по себе, ядро не умеет конвертировать между стандартными и расширенными идентификаторами. Учетом пользователей и групп, а также конвертацией идентификаторов из одного представления в другое заведует демон memberd.
Pid-файлы
Существуют определенные соглашения, которые регламентируют поведение демона. В частности, на старте демон должен создать файл /var/run/<имя-демона>.pid, и записать в него собственный идентификатор процесса. Это действие преследует две цели: во-первых, этот файл помогает всем заинтересованным сторонам найти процесс демона. Во-вторых, если по ошибке был запущен второй экземпляр демона, наличие pid-файла будет сигнализировать что демон уже запущен, следовательно надо предупредить пользователя, и завершить процесс. Тут правда есть одна проблема.
В принципе, демон может внезапно помереть, и не подтереть за собой pid-файл. Чтобы демон не отказался перезапускаться в такой ситуации (pid-файл то есть, значит демон уже запущен?) используют рекомендательные блокировки на файлах. Демон не просто создает pid-файл, он блокирует файл в эксклюзивном режиме (поскольку блокировка рекомендательная, она не препятствует чтению файла другими процессами). Блокировки на файлах автоматически снимаются при завершении процесса (в том числе, аварийном). Если нам встретился незаблокированный pid-файл, мы его просто проигнорируем.
Pid-файлы - хороший пример UNIX way. Во-первых, это решение надежно исключает одновременный запуск нескольких экземпляров демона, и не требует никакой специальной поддержки от ОС. Во-вторых, это не слишком надежный механизм для получения идентификатора процесса демона. Хотя каждая из операций создания/открытия файла, стирания старого содержимого и записи PID-а атомарна, это три отдельные операции, поэтому если не повезет, другие программы могут обнаружить pid-файл в неконсистентном состоянии. Но это небольшая проблема, поскольку демоны стартуют и завершаются сравнительно редко.
Пример анти UNIX-way в этой ситуации - добавляя сложность пытаться починить изначально дырявую абстракцию. Я видел программы, которые получали список активных процессов, чтобы проверить, что за данным pid скрывается именно тот процесс, который они ожидали. Если вам нужен надежный канал для связи с демоном, используйте сокеты.
Running with the least privileges
Есть хороший принцип - наделять демон минимально необходимыми привелегиями. Тогда, когда демон взломают, плохие парни не получат полный контроль над системой. Часто на старте демону нужны привелегии супер-пользователя. Например, чтобы открыть TCP порт ниже 1024-ого или создать файл в /var/run. Хорошая идея после инициализации отказаться от лишних привелегий и из root-а стать (например) nobody. Правда впереди нас ждет одна проблема.
Когда демон будет завершаться, ему потребуется удалить pid-файл. В стандартной UNIX-ной модели прав доступа чтобы удалить файл нужны права записи в объемлющую директорию. Очевидно, у nobody нет прав записи в /var/run. UNIX-way в данной ситуации… просто забить - не удалять файл. Все кто работает с pid-файлами и так готовы к ситуации, когда pid-файл есть, а демона уже нет.
Анти UNIX-way в этой ситуации - извратиться, и как-нибудь добиться удаления pid-файла. Например вспомнить, что помимо стандартной UNIX-ной модели прав доступа, современные системы поддерживают ACL. ACL позволяет дать права на удаление конкретного файла определенному пользователю, не открывая целиком директорию на запись.
Особого смысла я в этом не вижу - в понедельник, придя на работу, вырежу код работающий с ACL-лями из проекта.