Зачем нужен pid файл

Обновлено: 06.07.2024

Прежде всего, позвольте мне подчеркнуть, что мне в действительности нравится код Upstart, он очень хорошо документирован и в нем легко ориентироваться. В общем на его примере должны учиться другие проекты (включая мой).

Я это сказал, но я не могу сказать, что в целом согласен с подходом используемом в Upstart. Но для начала, чуть больше об Upstart.

Upstart не разделяет код с sysvinit, и его функциональность представляет из себя надстройку и он предоставляет некоторую степень совместимости с хорошо известными скриптами SysV. Его главная фишка — это событийно-ориентированный подход: запуск и остановка процессов привязывается к событиям в системе, где событием может выступать множество разных вещей, такие как: доступность сетевого интерфейса или запуск какой-либо программы.

Upstart сериализует службы через эти события: если был послан сигнал syslog-started он используется как сигнал чтобы запустить D-Bus чтобы Syslog мог использовать его. Далее когда будет послан сигнал dbus-started, будет запущен NetworkManager, так как теперь он может использовать D-Bus и так далее и так далее.

Некоторые могли бы сказать, что таким способ текущие реальные зависимости которые существуют и понятны администраторам просто были конвертированы и закодированы в набор событий и правил поведения: каждое логическое правило "a нуждается в b", о котором беспокоится администратор/разработчик превращается в «запустить a когда запустится b» плюс «остановить a когда будет остановлен b». В некоторых ситуациях это просто упрощение вещей: для кода в самом Upstart. Тем не менее я бы поспорил, что это упрощение вещей на самом деле является пагубным. Прежде всего, логически зависимости никуда не деваются, человек, который пишет Upstart файлы теперь вынужден вручную конвертировать эти логические зависимости в набор событий и правил поведения (в действительности два правила для каждой зависимости). В итоге, вместо того чтобы позволить машине выяснить, что ему делать, основываясь на зависимостях, пользователь должен вручную конвертировать зависимости в простой набор событий/правил поведения. Также, из-за того, что информация о зависимости никогда не кодируется, то она не доступна во время выполнения, что означает, что администратор, который пытается выяснить, почему произошло то или иное, например, почему a запустилось, когда запустилось b, то у него нет шансов выяснить это.

Более того, система событий переворачивает с ног на голову все зависимости. Вместо того чтобы, минимизировать количество работы (что должна делать хорошая система загрузки, как было отмечено в начале статьи), он в действительности увеличивает количество работы, которое необходимо выполнить. Или другими словами, вместо того иметь четкую цель и делать только то, что в действительности необходимо чтобы достичь цели, он делает один шаг, и после завершения этого шага, он выполняет все шаги, которые возможно могли бы следовать за ним.

Проще говоря: факто того, что пользователь запустил D-Bus не является индикатором того, что надо запускать NetworkManager (но это то, что на самом деле сделал бы Upstart). В обратном случае данное заявление тоже справедливо: когда пользователь запрашивает NetworkManager, это однозначно является индикатором того, что должен быть запущен D-Bus (что в основном ожидают увидеть большинство пользователей, верно?).

Хорошая система загрузки должна запускать только то, что необходимо и только по требованию. И либо используя «ленивую» загрузку, либо используя параллелизм заблаговременно. Тем не менее он не должен запускать больше чем необходимо, в частности не все, что установлено и может использовать какую-либо службу должно быть запущено.

Наконец, я не вижу реальной пользы использования логики событий. Мне представляется, что большинство событий, которые представлены в Upstart на самом деле не являются пунктуальными по природе, а имеют некоторое время выполнения: служба запускается, выполняется и останавливается. Когда какое-либо устройство подключено, доступно и снова отключено. Точка монтирования в процессе подключения, полностью подключена и отключена. Кабель питания подключен, система питается от сети и кабель питания отключен. Система загрузки или процесс наблюдатель должен управлять минимальным количеством событий чтобы соблюдать пунктуальность, большинство из которых последовательность из запуска, условия и остановки. И снова эта информация не доступна в Upstart, потому что он фокусируется на единичных событиях и игнорирует зависимости времени выполнения.

Оставив все это позади, Upstart является хорошей «сиделкой» для служб, даже если некоторые решения кажутся неоднозначными (читайте выше), и имеет много не реализованных возможностей (также читайте выше).

Есть еще другие системы загрузки кроме Upstart, sysvinit и launchd. Большинство из них предлагают немного больше чем Upstart или sysvinit. Наиболее интересный соперник — это Solaris SMF, который поддерживает правильные зависимости между службами. Тем не менее, во многих случаях они чересчур сложные и позвольте сказать слегка академичные в их чрезмерном использовании XML и новой терминологии для хорошо известных вещей. Он также тесно связан с специфичными особенностями Solaris таким как контрактная система.

Собираем все вместе

Итак, сейчас удачное время для второго перерыва, перед тем как я объясню, как должен себя вести хороший PID 1 и что большинство текущих систем делают, и выясним где собака зарыта. Так что идите и налейте новую кружку кофе. Это будет стоить того.

Вы вероятно догадались: то, что я предложил выше как требования и функционал для идеальной системы загрузки на самом деле теперь доступно, в (пока что экспериментальной) системе загрузке зовущимся systemd и которую я хочу анонсировать прямо сейчас и здесь! И снова, вот здесь код. И здесь быстрый обзор его функционала и зерна рациональности стоящим за ними.

systemd запускает и управляет всей системой (обратите внимание на имя. ). Он реализует весь фунционал обозначенный выше и еще несколько. Все основано на понятии юнитов. Юнит имеют тип и имя. Так как юниты обычно загружают свою конфигурацию с файловой системы, следовательно, именами юнитов являются имена файлов. Например: юнит avahi.service считывает свой конфигурационный файл с таким же именем, и конечно же одновременно является юнит инкапсулирующим демон Avahi. Существует несколько типов юнитов:

service: это самый очевидный тип юнитов: демоны, которые могут быть запущены, остановлены, перегружены и вновь инициализированы. Для совместимости с SysV мы не только поддерживаем свои собственные конфигурационные файлы, но еще имеем возможность считать классические скрипты загрузки SysV, в частности мы парсим LSB заголовок, если он присутствует. Следовательно /etc/init.d ни что иное как еще один источник конфигурационных файлов
socket: этот тип юнита инкапсулирет сокет в файловой системе или в Интернете.
На данный момент мы поддерживаем AF_INET, AF_INET6, AF_UNIX сокетов следующих типов: потоковые, датаграммы и последовательных пакетов. Мы также поддерживаем классические FIFO как транспорт. Каждый socket юнит имеет соответствующий service юнит, который запускается, как только будет получено первое соединение на сокет или на FIFO. Например: nscd.socket запускает nscd.service на входящем соединении.
device: этот тип юнита инкапсулирует устройство в Linux системе. Если устройство помечается через udev правило, то оно появится в как device юнит в systemd. Свойства, устанавливаемые с помощью udev могут быть использованы как источник конфигурации для установления зависимостей device юнита.
mount: этот тип юнита инкапсулирует точку монтирования в файловой системе. systemd наблюдает за всеми точками монтирования в то время как они подключается и далее на их жизненном пути, и может быть также использован для подключения и отключения точек монтирования. /etc/fstab используется как дополнительный источник для точек монтирования, точно также как скрипты загрузки SysV могут быть использованы как дополнительный источник конфигурации для юнитов типа service.
automount: это тип юнита инкапсулирует автоматическую точку монтирования в файловой системе. Каждый automount юнит имеет соответствующий mount юнит, который запускается (т.е. подключается) как только будет сделана попытка доступа к папке авто-подключения.
target: этот тип юнита используется для логической группировки юнитов: вместо того чтобы на самом деле делать что-то полезное он просто ссылается на другие юниты, вследствие чего они могут управляться вместе. Примером может служить: multi-user.target, который играет роль уровня запуска 5 в классической системы SysV, или bluetooth.target, который запрашивается как только к системе подключается какой-либо bluetooth донгл и который просто запускает все службы связанные с bluetooth, которые в ином случае не были бы запущены: bluetoothd и obexd как пример
snapshot: этот тип юнита похож на target и ничего не делают по своей сути и единственной его целью является ссылка на другие юниты. Снапшоты могут быть использованы чтобы сохранить/откатывать состояние всех сервисов и юнитов системы загрузки. В основном он предназначен для использования в двух случаях: позволить пользователю временно войти в определенное состояние такое как «Экстренная оболочка», т.е. прерывание текущих служб и простой способ вернуться в предыдущему состоянию, т.е. запуск всех служб, которые были временно остановлены. Также он может использоваться как простой способ приостановки системы (сон): существует много сервисов, которые ведут себя не корректно, когда система уходит в режим сна, и частенько было бы хорошей идеей просто остановить эти службы до сна и запустить после выхода система из режима сна.

А вот короткий список особенностей:

Должен заметить, что systemd использует много специфичных особенностей Linux и не ограничивает себя POSIX. Это дает нам доступ к огромному функционалу, которую не может обеспечить система, предназначенная для переноса на другие операционные системы.

Я часто вижу, что программы указывают файлы pid и lock. И я не совсем уверен, что они делают.

Например, при компиляции nginx:

Может кто-нибудь пролить свет на этот?

pid-файлы пишутся некоторыми программами для записи их идентификатора процесса во время их запуска. Это имеет несколько целей:

Это сигнал другим процессам и пользователям системы, что эта конкретная программа запущена или, по крайней мере, успешно запущена.
Это позволяет очень легко написать скрипт, проверить, работает ли он, и выполнить простую kill команду, если кто-то хочет завершить его.
Для программы это дешевый способ узнать, не был ли предыдущий запущенный экземпляр успешно завершен.

Разумеется, наличие pid-файла не гарантирует, что этот конкретный идентификатор процесса работает, поэтому этот метод не на 100% надежен, но во многих случаях «достаточно хорош». Проверка наличия определенного PID в таблице процессов не является полностью переносимой в UNIX-подобных операционных системах, если только вы не хотите зависеть от ps утилиты, которую может быть нежелательно вызывать во всех случаях (и я считаю, что некоторые UNIX-подобные операционные системы В ps любом случае реализовать по- другому).

Файлы блокировки используются программами для обеспечения того, чтобы два (с хорошим поведением) отдельных экземпляра программы, которые могут одновременно работать в одной системе, не обращались к чему-то другому одновременно. Идея состоит в том, что прежде чем программа получит доступ к своему ресурсу, она проверяет наличие файла блокировки, и, если файл блокировки существует, либо выдает ошибку, либо подождите, пока она не исчезнет. Когда он не существует, программа, желающая «приобрести» ресурс, создает файл, а затем другие экземпляры, которые могут встретиться позже, будут ожидать завершения этого процесса. Конечно, это предполагает, что программа, «получающая» блокировку, фактически снимает ее и не забывает удалить файл блокировки.

Это работает, потому что файловая система во всех UNIX-подобных операционных системах обеспечивает сериализацию , что означает, что в любой момент времени происходит только одно изменение файловой системы. Вроде как блокировки с базами данных и тому подобное.

Процесс — это экземпляр запущенной программы. Всякий раз, когда в терминале выполняется какая-нибудь команда (например, команда pwd ), система создает/запускает новый процесс.

Типы процессов

В Linux существует три основных типа процессов:

Как Linux идентифицирует процессы?

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

Родительские процессы — это процессы, которые во время своего выполнения создают другие процессы.

Дочерние процессы — эти процессы, создаваемые другими процессами во время своего выполнения.

Примечание: В любой момент времени в системе не существует двух процессов с одинаковым PID. Вновь создаваемому процессу может быть назначен ранее использованный свободный PID.

Состояния процесса в Linux

Рассмотрим основные состояния процесса:

Выполнение — процесс либо запущен (текущий процесс в системе), либо готов к запуску (ожидает передачи на выполнение процессору).

Ожидание — процесс ожидает наступления некоторого события (пользовательского ввода, сигнала от другого процесса и т.п.) или выделения системных ресурсов. Кроме того, ядро также различает два типа ожидающих процессов:

прерываемые ожидающие процессы — могут быть прерваны сигналами;

непрерываемые ожидающие процессы — процессы ожидают непосредственно на аппаратном уровне и не могут быть прерваны каким-либо событием/сигналом.

Завершен — процесс был остановлен, как правило, путем получения сигнала штатного завершения работы exit().

Как получить идентификатор (PID) процесса

Для отображения идентификатора нужного вам процесса можно использовать команду pidof, например:

$ pidof init
$ pidof bash
$ pidof systemd

Примечание: На вышеприведенном скриншоте вы можете видеть, что процессу init назначен PID=1 , а процессу systemd — PID=881 , хотя системой инициализации в Debian является именно systemd. Детально о том, почему возникла такая путаница, читайте здесь.

Чтобы вывести PID и PPID текущей оболочки, выполните:

$ echo $$
$ echo $PPID

Запуск интерактивного процесса в Linux

Как только вы выполните какую-нибудь команду или программу (например, firefox ), она создаст в системе соответствующий процесс. Вы можете запустить процесс переднего плана (он будет подключен к терминалу, ожидая пользовательского ввода) следующим образом:

Запуск фонового процесса в Linux

Запуск процесса в фоновом режиме полезен только для программ, которые не нуждаются в пользовательском вводе (через оболочку). Перевод задания в фоновый режим обычно выполняется, когда ожидается, что выполнение задания займет много времени.

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

Чтобы запустить процесс в фоновом режиме, используйте символ & после имени запускаемой программы. В этом случае процесс не будет принимать пользовательский ввод, пока не переместится на передний план:

Отслеживание активных процессов

Существует несколько различных инструментов для просмотра/перечисления запущенных в системе процессов. Двумя традиционными и хорошо известными из них являются команды ps и top:

Команда ps

Отображает информацию об активных процессах в системе, как показано на следующем скриншоте:

Для получения дополнительной информации о процессах, запущенных текущим пользователем, применяется опция -f :

Столбцы, присутствующие в выводе команды ps , имеют следующие значения:

UID — идентификатор пользователя, которому принадлежит процесс (тот, от чьего имени происходит выполнение).

PID — идентификатор процесса.

PPID — идентификатор родительского процесса.

C — загрузка CPU процессом.

STIME — время начала выполнения процесса.

TTY — тип терминала, связанного с процессом.

TIME — количество процессорного времени, потраченного на выполнение процесса.

CMD — команда, запустившая этот процесс.

Также можно отобразить информацию по конкретному процессу, используя команду ps -f [PID] , например:

Есть и другие опции, которые можно использовать вместе с командой ps :

-a — показывает информацию о процессах по всем пользователям;

-x — показывает информацию о процессах без терминалов;

-u — показывает дополнительную информацию о процессе по заданному UID или имени пользователя;

-e — отображение расширенной информации.

Если вы хотите вывести вообще всю информацию по всем процессам системы, то используйте команду ps –aux :

Обратите внимание на выделенный заголовок. Команда ps поддерживает функцию сортировки процессов по соответствующим столбцам. Например, чтобы отсортировать список процессов по потреблению ресурсов процессора (в порядке возрастания), введите команду:

$ ps -aux --sort=%cpu

Если вы ходите выполнить сортировку по потреблению памяти (в порядке убывания), то добавьте к имени интересующего столбца знак минуса:

$ ps -aux --sort=-%mem

Еще один очень популярный пример использования команды ps — это объединение её и команды grep для поиска заданного процесса по его имени:

$ ps -aux | grep bash

Команда top

Команда top отображает информацию о запущенных процессах в режиме реального времени:

PID — идентификатор процесса.

USER — пользователь, которому принадлежит процесс.

PR — приоритет процесса на уровне ядра.

NI — приоритет выполнения процесса от -20 до 19 .

VIRT — общий объем (в килобайтах) виртуальной памяти (физическая память самого процесса; загруженные с диска файлы библиотек; память, совместно используемая с другими процессами и т.п.), используемой задачей в данный момент.

RES — текущий объем (в килобайтах) физической памяти процесса.

SHR — объем совместно используемой с другими процессами памяти.

%CPU — процент используемых ресурсов процессора.

%MEM — процент используемой памяти.

TIME+ — количество процессорного времени, потраченного на выполнение процесса.

COMMAND — имя процесса (команды).

< — процесс с высоким приоритетом;

N — процесс с низким приоритетом;

l — многопоточный процесс;

s — лидер сессии.

Примечание: Все процессы объединены в сессии. Процессы, принадлежащие к одной сессии, определяются общим идентификатором сессии — идентификатором процесса, который создал эту сессию. Лидер сессии — это процесс, идентификатор сессии которого совпадает с его идентификаторами процесса и группы процессов.

Команда glances

Команда glances — это относительно новый инструмент мониторинга системы с расширенными функциями:

Примечание: Если в вашей системе отсутствует данная утилита, то установить её можно с помощью следующих команд:

$ yum install -y glances

$ sudo apt-get update
$ sudo apt-get install glances

Управление процессами в Linux

Также в Linux присутствуют некоторые команды для управления процессами:

kill — посылает процессу сигнал завершения работы;

pkill — завершает процесс по его имени;

pgrep — ищет процесс по его имени (и, опционально, по имени запустившего его пользователя);

killall — завершает все активные процессы.

Ниже приведены несколько основных примеров их использования:

$ pgrep -u diego firefox
$ kill 6516
$ pgrep -u diego firefox
$ pgrep -u diego glances
$ pkill glances
$ pgrep -u diego glances

Отправка сигналов процессам

Основополагающим способом управления процессами в Linux является отправка им соответствующих сигналов. Для перечисления списка всех доступных сигналов, введите команду:

Большинство сигналов предназначены для внутреннего использования системой или для программистов, когда они пишут код. Ниже приведены наиболее полезные сигналы:

SIGHUP (1) — отправляется процессу, когда его управляющий терминал закрыт.

SIGINT (2) — отправляется процессу управляющим терминалом, когда пользователь прерывает процесс нажатием клавиш Ctrl+C.

SIGQUIT (3) — отправляется процессу, если пользователь посылает сигнал выхода Ctrl+D.

SIGKILL (9) — этот сигнал немедленно завершает (убивает) процесс, и процесс не будет выполнять никаких операций очистки за собой.

SIGTERM (15) — сигнал завершения программы (отправляется командой kill по умолчанию).

SIGTSTP (20) — отправляется процессу управляющим терминалом с запросом на остановку; инициируется пользователем нажатием клавиш Ctrl+Z.

Ниже приведены примеры команды kill для уничтожения приложения firefox с помощью PID, после его зависания:

$ kill -SIGKILL 2275

Чтобы убить приложение, используя его имя, применяются команды pkill или killall , например:

Изменение приоритета процесса

В системе Linux все активные процессы имеют определенный приоритет выполнения, задаваемый так называемым nice-значением. Процессы с более высоким приоритетом обычно получают больше процессорного времени, чем процессы с более низким приоритетом. Однако пользователь с root-правами может повлиять на это с помощью команд nice и renice.

Узнать значение приоритета команды можно по выводу команды top (столбец NI):

Используйте команду nice , чтобы задать NI-значение для запускаемого процесса. Имейте в виду, что обычные пользователи могут задавать данный параметр в диапазоне от 0 до 20 тем процессам, которыми они владеют. Только пользователь root может использовать отрицательные значения приоритета.

Чем больше nice-значение, тем меньшим приоритетом будет обладать процесс. Например, вы можете задать приоритет для запускаемого процесса следующим образом:

$ nice -n 10 firefox

Чтобы изменить приоритет уже запущенного процесса, используйте команду renice следующим образом:

$ renice +8 5547
$ renice +8 1151

На данный момент это всё! Если у вас есть какие-либо вопросы или дополнительные идеи, вы можете поделиться ими с нами с помощью комментариев.

Управление компьютером кажется простым занятием, но так ли это? Километры машинного кода, организация взаимодействия программ, ресурсов и пользователя. Важно не только создать жизнеспособную среду, но и придать ей возможность дальнейшего развития и оптимизации. Разработчикам же остается использовать доступный инструментарий.

Функции операционной системы

Прежде чем ответить на вопрос, что такое pid, важно понять функциональные возможности, от реализации которых зависят и функции идентификатора:

работа с данными, запуск и остановка ПО;
взаимодействие с устройствами ввода/вывода;
распределение и организация оперативной памяти;
обеспечение доступа к энергозависимым носителям;
оптимизация ресурсов машины;
обеспечение безопасного доступа каждого объекта к ресурсам машины;
надежные вычисления;
защита данных от вредоносного ПО и намеренного взлома.

Базовые понятия

Дальнейшее повествование будет базироваться на приведенных ниже понятиях. Пренебрегая этим пунктом, будет сложно понять, что такое pid.

Процесс – это любой объект, использующий ресурсы системы, согласно стандарту ISO. 9000:2000 – совокупность операций, взаимодействие которых преобразует входящие данные в исходящие.

Любой процесс характеризуется несколькими параметрами:

машинным кодом;
исполняемым кодом;
зарезервированным фрагментом памяти (иногда – виртуальной);
атрибутами безопасности;
входными/выходными данными;
стеком вызова, который следит за активностью каждого объекта;
так называемой «кучей», хранящей промежуточные результаты операций и вычислений.

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

Понятие идентификатора

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

Чтобы поближе познакомиться с указателем, можно пойти двумя путями:

Вызываем диспетчер задач правой кнопкой мыши на панели задач. Далее, переходим во вкладку «Процессы», выбираем меню «Вид». Находим пункт «Выбрать столбцы», в открывшемся диалоговом окне ставим галочку для PID. В командной строке прописываем tasklist.
Для Unix-систем верна и другая тактика. Здесь рекомендуется использовать команду ps. С ее помощью можно найти идентификатор для конкретной программы.

Разрешается использование уникального номера для поиска потенциально вредоносного ПО. Дело в том, что вирусы часто маскируются под «благопристойные» файлы, указатель же дает четкое представление о безопасности рассматриваемого объекта. Нужно только уметь распознать, «что такое pid» из кодового потока системных и менее значительных процессов.

Современные языки программирования позволяют «вычленить» из обычного номера информацию об интересующем объекте. На программном уровне можно разработать код, напрямую взаимодействующий с pid. Что это дает? Ценой пары кликов удастся вывести полный путь к интересующему файлу или программе. По сути, это позволит не только понять и оптимизировать работу системы (количество необходимых ресурсов), но и защитить машину от потенциальной угрозы.

Чтобы не запутаться

В электронике существует и pid-регулятор – электронное устройство, использующееся в системах автоматического управления. Позволяет не только формировать сигнал управления, но и влиять на показатели точности и качества переходного процесса.

Многие пользователи путают два понятия, но они абсолютно разные. После прочтения статьи окончательно должен иссякнуть вопрос, «что такое pid процесса», так как приведенные сведения дают полное описание и возможности указателя. Важно понимать, что функционирование «операционки» напрямую зависит от каждого винтика фундаментальной системы. Сегодня был рассмотрена лишь частичка на микроуровне компьютера как машины.

Читайте также: