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

Поиск идентификатора процесса

Каждому процессу, работающему в Windows, присваивается уникальное десятичное число, которое называется идентификатором процесса (PID). Это число используется несколькими способами, например для указания процесса при присоединении к нему отладчика.

В этом разделе описывается, как определить piD для конкретного приложения с помощью диспетчера задач, команды списка задач Windows, служебной программы TList, команды PowerShell Get-Process или отладчика.

Диспетчер задач

Диспетчер задач можно открыть несколькими способами, но проще всего нажать клавиши CTRL+ALT+DELETE, а затем выбрать диспетчер задач.

В Windows сначала щелкните Дополнительные сведения , чтобы развернуть отображаемые сведения. На вкладке Процессы выберите Сведения , чтобы просмотреть идентификатор процесса, указанный в столбце PID .

Щелкните имя любого столбца для сортировки. Щелкните правой кнопкой мыши имя процесса, чтобы просмотреть дополнительные параметры процесса.

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

Команда списка задач

Используйте встроенную команду windows tasklist из командной строки для отображения всех процессов, их идентификаторов piD и различных других сведений.

C:\>tasklist Image Name PID Session Name Session# Mem Usage ========================= ======== ================ =========== ============ System Idle Process 0 Services 0 8 K System 4 Services 0 7,428 K Secure System 104 Services 0 40,344 K Registry 164 Services 0 146,596 K smss.exe 592 Services 0 1,176 K csrss.exe 896 Services 0 6,224 K wininit.exe 980 Services 0 6,572 K . 

Используйте tasklist /? для отображения справки из командной строки.

Служебная программа TList

Средство просмотра списка задач (TList), или tlist.exe, — это служебная программа командной строки, которая отображает список задач или процессов в пользовательском режиме, которые в настоящее время выполняются на локальном компьютере. Список TList включен в средства отладки для Windows. Сведения о том, как скачать и установить средства отладки, см. в разделе Средства отладки для Windows.

Если вы установили пакет драйверов Windows в каталоге по умолчанию на 64-разрядном компьютере, средства отладки находятся здесь:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\

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

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64>tlist -t System Process (0) System (4) smss.exe (592) Memory Compression (3376) Secure System (104) Registry (164) csrss.exe (896) wininit.exe (980) services.exe (660) svchost.exe (1232) WmiPrvSE.exe (6008) dllhost.exe (1748) WmiPrvSE.exe (1860) . 

Дополнительные сведения см. в разделе TList.

Команда отладчика .tlist

Если в рассматриваемой системе уже запущен отладчик пользовательского режима, команда .tlist (список идентификаторов процессов) отобразит список всех идентификаторов piD в этой системе.

Команда Get-Process PowerShell

Для работы со сценариями автоматизации используйте команду PowerShell Get-Process. Укажите конкретное имя процесса, чтобы просмотреть идентификатор процесса.

C:\> Get-Process explorer Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 2520 404 108948 179284 1,702.95 7656 1 explorer 

Дополнительные сведения см. в разделе Get-Process.

Дополнительные ресурсы

Дополнительные сведения о внутренних компонентах Windows (включая контекст, потоки и процессы) см. в дополнительных ресурсах, таких как Windows Internals Павла Йосифовича, Марка Руссиновича, Дэвида Соломона и Алекса Ионеску.

Совместная работа с нами на GitHub

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

Windows driver documentation

Файлы, каталоги и папки в Linux. Структура файловой системы

В операционной системе Linux файловая система отличается организованной структурой. Если вы только перешли с Windows, вы можете столкнуться с некоторыми затруднениями, во многом из-за отсутствия чёткого понимания о принадлежности каждой директории. В данной статье будет рассмотрена структура файловой системы, в результате чего смысл применения большинства папок в Linux директории (directory) станет вам ясен.

В первую очередь, обратите внимание на следующую таблицу ниже:

Теперь следует разобрать всё более подробно.

/ — корень

Главный каталог в системе. Здесь нет дисков, как в Виндовс. По большему счёту, это и есть файловая система Линукс. Адреса всех существующих файлов начинаются с корневой директории Linux, а дополнительные разделы подключаются к папкам корневого каталога.

Читать или менять содержимое в данном каталоге может лишь root-пользователь (user). Домашний каталог пользователя root — /root.

/bin — бинарные файлы пользователя

Содержит файлы исполняемого типа. Программы, с которыми можно работать в однопользовательском режиме и прочие утилиты, которые применяются, пока не подключён каталог /usr/.

/sbin — системные исполняемые файлы

Во-первых, как и в случае с /bin, содержатся исполняемые файлы, доступные на ранних этапах загрузки. Во-вторых, тут располагаются программы, выполняемые с правами суперпользователя, те же утилиты обслуживания и пр.

/etc

В этой папке Linux расположены конфигурационные файлы всех программ, которые установлены в системе. Также есть скрипты для запуска демонов, автозагрузки программ и т. п. Главное, что следует запомнить, — речь идёт о файлах по настройке и конфигурации.

/dev — файлы устройств

Как вы знаете, в операционной системе Linux «всё есть файл». И различные внешние устройства тоже. В результате, любые подключённые микрофоны, клавиатуры, флешки и т. п. — это лишь файлы, которые находятся в каталоге /dev.

/proc — информация о процессах

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

/var — переменные файлы

Речь идёт о файлах, которые часто меняются — это базы данных, кеши, системные журналы и пр. Следует подробнее рассмотреть каталог Linux из папки /var/: • /var/log — файлы логов; • /var/lib — базы данных; • /var/lock — файлы блокировок; • /var/mail — почта; • /var/spool — принтер, печать; • /var/run — pid процессов.

/tmp

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

/usr — программы пользователя

Этот каталог является самым большим и имеет много функций. Вкратце рассмотрим его структуру: • /usr/bin/ — исполняемые файлы (графические редакторы, браузеры, плееры — не используются при загрузке системы); • /usr/sbin/ — бинарные файлы программ, предназначенных для системного администрирования (выполняются с правами суперпользователя); • /usr/lib/ — библиотеки для программ из /usr/sbin либо /usr/bin; • /usr/local — файлы пользователя (программы, библиотеки и настройки, созданные пользователем).

/home — домашняя папка

Linux директория пользователей, где содержатся домашние каталоги всех пользователей. В данных каталогах пользователи хранят личные файлы, программные настройки и пр. Аналогия с Windows — папка на диске C. Но тут есть разница: home располагается на отдельном разделе, в результате чего при переустановке системы все данные и настройки сохраняются.

/boot — файлы загрузчика

Linux директория, где содержатся файлы, связанных с загрузчиком системы (ядро vmlinuz, образ initrd и пр.).

/lib — системные библиотеки

Тут располагаются файлы системных библиотек.

/opt — дополнительные программы

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

/mnt — монтирование

Сюда сисадмины монтируют внешние либо дополнительные файловые системы Linux.

/media — съемные носители

Монтируются подключаемые внешние накопители — оптические диски, USB-устройства.

/srv — сервер

Файлы сервисов и серверов. Как пример — web-сервер Apache.

/run — процессы

Каталог включает в себя PID-файлы процессов, однако в отличие от /var/run, он располагается в TMPFS, в результате чего всё удаляется после перезагрузки.

/sys — информация о системе

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

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

Переосмысление PID 1. Часть 4

Прежде всего, позвольте мне подчеркнуть, что мне в действительности нравится код 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, в частности синтаксис основанный на условиях таких как start on (local-filesystem and net-device-up IFACE=lo) в файлах правил Upstart-а. Тем не менее, для меня эта кажется больше попыткой исправить систему, в коде которого есть жесткий изъян.

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

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

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

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

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

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

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

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

1. Для каждого процесса, который порождается, вы можете контролировать: среду, ограничения ресурсов, рабочую и корневую директорию, umask, настройки OOM киллера, уровень nice, класс IO и приоритетность, политики CPU и приоритетность, притяжение к CPU, id пользователя, id группы, id побочных групп, папки для чтения/записи и папки без права доступа, общие/частные/вторичные флаги монтирования, набор возможностей/ограничений, атрибуты безопасности, установки планировщика CPU, приватные /tmp пространство, cgroup для различных подсистем. Также вы можете легко соединить stdin/stdout/stderr службы к syslog, /dev/kmsg или любой TTY. Если подсоединен к TTY для ввода, то systemd убеждается, что процесс имеет эксклюзивный доступ к TTY, либо ждет доступа или форсирует его.
2. Каждый запущенный процесс получает свой cgroup (на данный момент только в подсистеме отладки, так как подсистема отладки не используется в других целях и делает не больше чем просто группировка процессов) и очень легко настроить systemd чтобы каждому сервису был присвоен свой cgroup, настроенный вне systemd, скажем через утилиты libcgroups.
3. Файлы конфигурации использует синтаксис, который максимально следует хорошо известным .desktop файлам. Это простой синтаксис, парсер к которому присутствует во многих библиотеках. Также, он позволяет нам сослаться на существующие инструменты для i18n в описаниях служб. Администраторам и разработчикам не придется учить новый синтаксис.
4. Как было упомянуто, мы поддерживаем совместимость с скриптами загрузки SysV. Мы пользуемся преимуществом LSB и Red Hat chkconfig заголовков если они присутствуют. Если они не представлены мы пытаемся выжать лучшее из доступной информации, типа приоритеты запуска в /etc/rc.d. Скрипты загрузки SysV используется как дополнительный источник конфигурации, следовательно, упрощается путь миграции на systemd. Опционально мы можем считать классические PID файлы для служб чтобы идентифицировать мастер процесс службы. Заметьте, что мы берем LSB заголовки и конвертируем их в систему зависимостей systemd. Отвлеченная заметка: Upstart не может собирать и использовать такого рода информацию. Загрузка с помощью Upstart на системе где преобладают LSB SysV скрипты будет не распараллеленной, хотя на той же системе с systemd будет. В действительности, для Upstart все скрипты загрузки SysV выполняются вместе как одно задание, тогда как для systemd они являются как еще один источник конфигурации и все они управляются и обозначаются индивидуально, как нативная служба systemd.
5. Похожим способом мы считываем существующий /etc/fstab, и считаем его как дополнительный источник конфигурации. Используя fstab опцию comment= мы можем даже пометить элемент в /etc/fstab как контролируемую systemd точку автомонтирования.
6. Если один и тот же юнит настроен в нескольких источниках конфигураций (например, есть файл /etc/systemd/system/avahi.service и /etc/init.d/avahi) тогда приоритет получит нативный файл конфигурации, игнорируя устаревший файл конфигурации, позволяя пакет использовать как SysV скрипт так и файл конфигурации systemd еще некоторое время.
7. Мы поддерживаем простой механизм шаблонов/экземпляров. Например: вместо того чтобы поддерживать шесть конфигурационных файлов для шести getty, мы просто поддерживаем один getty@.service экземпляр которого будет создан для getty@tty2.service и так далее. Интерфейсная часть может быть даже унаследована выражениями зависимостей, т.е. легко закодировать что служба dhcpd@eth0.service запускает avahi-autopid@eth0.service
   при этом оставляя часть строки — eth0 — замаскированным.
8. Для активации сокета мы поддерживаем полную совместимость с традиционными режимами inetd, так же как очень простой режим, который пытается имитировать метод активации launchd и это рекомендованный метод для новых служб. Режим inetd позволяет передать только один сокет демону, тогда как нативно поддерживаемый режим позволяет передать сколько угодно файловых дескрипторов. Мы также поддерживаем один экземпляр на соединение, также как один экземпляр на все соединения. В первом режиме мы называем cgroup службы, который будет запущен, с параметрами соединения, и используем логику шаблонизации упомянутую выше. Например: sshd.socket может породить службы sshd@192.168.0.1-4711-192.168.0.2-22 с названием cgroup sshd@.service/192.168.0.1-4711-192.168.0.2-22 (т.е. IP адрес и номера портов используются в названии экземпляра. Для сокета AF_UNIX мы используем PID и идентификатор клиентского соединения). Такой механизм предоставляет администраторам хороший способ идентифицировать различные экземпляры службы или контролировать их рантайм индивидуально. Нативный режим передачи сокетов очень легко реализовать в приложениях: если установлена переменная $LISTEN_FDS, то он будет содержать количество переданных сокетов и демон сможет найти их отсортированными как указано в .service файле, начиная с дескриптора 3 (хорошо написанный демон может также использовать fstat() и getsocketname() чтобы идентифицировать каждый из сокетов в случае если их передано больше одного). В дополнение мы устанавливаем переменную $LISTEN_PID в значение PID демона, который должен получить файловые дескрипторы, потому что переменные окружения как правило наследуется дочерним процессом и, следовательно, могли бы ввести в заблуждение следующие ниже по цепочке. Более того такая логика передачи сокета очень легко реализовать в демонах. Мы будем предоставлять BSD лицензированную эталонную реализацию, которая показывает, как работать с этим. Мы портировали парочку демонов реализующую данную схему.
9. В некоторой степени мы предоставляем совместимость с /dev/initctl. Эта совместимость в действительности реализована с помощью FIFO-активированных служб, которые просто конвертируют эти старые запросы в запросы D-Bus. В сущности, это означает, что старые shutdown, poweroff и похожие команды из Upstart и sysvinit продолжают работать и с systemd.
10. Мы также предоставляем совместимость с utmp и wtmp. Возможно даже немного более лучшую версию чем существующие utmp и wtmp.
11. systemd поддерживает несколько типов зависимостей между юнитами. After/Before может быть использована чтобы вмешаться в порядок активации юнитов. Также полностью ортогональные Requires и Wants, которые выражаются в позитивно требующую зависимость, либо обязательную, либо не обязательную. Также, существует Conflicts, который выражается в негативно требующую зависимость. Наконец, также существует еще три менее используемых типов зависимостей.
12. systemd имеют минимальную систему транзакций. Это значит: если юнит хотят запустить или остановить мы добавим службу и все её зависимости в временную транзакцию. Далее мы убедимся, что транзакция целостна (т.е. сортировка через After/Before все юнитов свободна от цикличности). Если это не так, попытаемся исправить это, и удалить не существенные задания из транзакции, который может убрать рекурсию. Также, systemd пытается сдерживать не существенные задания, которые могут помещать запуску службы. Не существенные запросы это те, которые напрямую не вовлечены, но которые подтягиваются через зависимости типа Wants. Наконец мы проверяем есть ли задания, противоречащие заданиям, которые уже были добавлены в очередь, что в последствии может прервать транзакцию. Если все гуд и транзакция консистентна (целостна) и её влияние минимизировано, тогда она будет слита с уже предстоящими заданиями и будет добавлена в очередь запуска. В действительности это означает, что перед выполнением запрошенной операции, мы проверим что имеет ли смысл её вообще выполнять, исправим её если возможно и «сдадимся» если на самом деле произойдет не разрешимая ситуация.
13. Мы записываем время запуска/остановки, как и PID и код выхода каждого процесса, который мы запускаем и за которым мы следим. Эти данные мы можем использовать чтобы построить перекрестные связи служб и их данных в abrtd, auditd и syslog. Представьте интерфейс пользователя, который подсвечивает падения демона, и предоставляет вам легкую навигацию к соответствующему пользовательскому интерфейсу для syslog, abrtd и auditd, который покажет сгенерированную информацию для этого демона по текущему запуску.
14. Мы поддерживаем повторное выполнение процесса загрузки самим собой в любое время. Состояние демона сериализуется до повторного выполнения и десериализуется после выполнения. Таким способом мы предоставляем простой способ облегчить обновления системы загрузки, а также передачу демона загрузки до конечного демона. Открытые сокеты и точки монтирования autofs правильно сериализуются, так что позволяют соединиться к ним все время, таким образом, что клиенты даже не заметят, что система загрузки перезапускает сама себя. Также факт того, что большая часть состояния служб закодирована в виртуальной ФС cgroup не позволяет нам продолжить выполнения без доступа к сериализованным данным. Путь кода повторного запуска в действительности очень похож на путь кода повторной загрузки конфигурации для системы загрузки, который гарантирует повторное выполнение (который реже запускается) тестируется также как перезагрузка конфигурации (который вероятно запускается более часто)
15. Начиная работу по удалению скриптов загрузки из системы загрузки, мы записали часть базовой настройки системы в С и перенесли его напрямую в systemd. Среди этого также подключение API файловых систем (т.е. виртуальные файловые системы типа /proc, /sys и /dev) и установка имени хоста.
16. Состояние сервера инспектируется и контролируется через D-Bus. Оно еще не завершено, но продвинулось далеко вперед.
17. Пока мы хотим подчеркнуть сокет-основанную и основанные на имени шины активацию, и, следовательно, поддержка зависимостей между сокетами и службами. Мы также поддерживаем несколько способов как такого рода сервисы могут сигнализировать о своей готовности: путем форкания (by forking) и имея статус остановки запускающего процесса (т.е. традиционное поведение daemonize()) также как наблюдение за шиной пока появится сконфигурированное имя службы.
18. Существует интерактивный режим, который спрашивает каждый раз подтверждения, когда процесс порождается systemd. Вы можете включить его передав systemd.confirm_spawn=1 в аргументах запуска ядра.
19. С параметром ядра systemd.default= вы можете указать с какого юнита начнется загрузка systemd. Обычно вы указываете что-то типа multi-user.target, но вы можете даже указать одну единственную службу вместо таргета. Для примера из коробки мы предоставляем emergency.service, который похож по своей полезности на init=/bin/bash, тем не менее имея преимущество запущенной системы загрузки, следовательно предоставляя возможность загрузки полноценной системы из экстренной оболочки.
20. Также присутствует минимальный пользовательский интерфейс, который позволяет запускать/останавливать/инспектировать службы. Он далек от полноценного пользовательского интерфейса, но полезен как инструмент отладки. Он написан на Vala (уу еее!!) и имеет имя systemadm

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

• Настройка Linux
• Системное администрирование
• *nix
• Серверное администрирование

Вопрос про pid-файлы

Программа использует pid-файлы и записывают туда PID. Далее она вычитывает список текущих процессов и удостоверяются, что 1) процесс с таким номером есть, 2) процесс с этим номером — именно эта программа. Получается, сам факт существования файла ни о чем не говорит, а номер в нем практически игнорируется. Зачем вообще создавать или проверять файлы если всё равно придется смотреть список процессов?

программы второго типа:

Программа берет flock() на /var/run/foo.pid, тоже кладет туда PID и больше, понятно, ничего не делает. Понятно зачем файл, но зачем записывать туда PID?

Я правильно понимаю, что обе эти программы делают совершенно бессмысленные вещи?

neschastnyjj86
01.02.18 20:06:31 MSK
anonymous
( 01.02.18 20:12:09 MSK )
Ответ на: комментарий от anonymous 01.02.18 20:12:09 MSK
anonymous
( 01.02.18 20:17:11 MSK )
Ответ на: комментарий от anonymous 01.02.18 20:12:09 MSK

И что ты хотел сказать-то это ссылкой? ты вопрос-то прочел вообще?

Кроме того, SO по содержательности и достоверности точности примерно как википедия.

neschastnyjj86
( 01.02.18 20:18:04 MSK ) автор топика
Ответ на: комментарий от neschastnyjj86 01.02.18 20:18:04 MSK

Если запущено более одной инстанции или процесса, то найти нужную извне родителя процессгруппы можно только зная, где лежит ее пидфайл. Иначе у тебя на 2 веб-сервера в списке процессов будет 10 httpd и только один из них обработает сигнал как положено.

anonymous
( 01.02.18 20:42:43 MSK )

сам факт существования файла ни о чем не говорит

Говорит о том что программа работает (или завершилась аварийно)

а номер в нем практически игнорируется

Если по данному номеру находится другое приложение (или приложения с таким PID нет вообще) то значит приложение, к которому относится PID-файл, завершилось некорректно.

То есть для того чтоб понять что софтина не запущена достаточно только проверить отсутствие pid-файла. Если он есть — проверяется действительно ли инстанс приложения работает или может он свалился и софт надо запускать заново.

micronekodesu ★★★
( 01.02.18 20:46:32 MSK )
Ответ на: комментарий от neschastnyjj86 01.02.18 20:18:04 MSK

Кроме того, SO по содержательности и достоверности точности примерно как википедия.

Как и ЛОР в общем то, чего пришли тогда?

micronekodesu ★★★
( 01.02.18 20:47:31 MSK )
Ответ на: комментарий от anonymous 01.02.18 20:42:43 MSK

то что ты написал не отвечает на вопрос.

найти нужную можно только зная, где лежит ее пидфайл

неправда. если они раздельные задачи то у них отличаются аргументы. некоторые программы даже специально используют отдельную оцию для этого, linkname в pppd например.

neschastnyjj86
( 01.02.18 21:03:00 MSK ) автор топика
Ответ на: комментарий от micronekodesu 01.02.18 20:47:31 MSK

Как и ЛОР в общем то, чего пришли тогда?

99% самоуверенные дауны конечно, но что поделать. на лоре есть некоторое число нормальных, очень грамотных людей.

neschastnyjj86
( 01.02.18 21:04:44 MSK ) автор топика

Не бывает такого чтобы две программы писали в один pid файл.

Это работает так:

• Демон открывает pid файл, берёт на него flock и записывает в него свой pid
• Внешние программы могут прочитать pid из pid файла и использовать его чтобы послать демону сигнал

И да, это безумная кривизна, ибо детерминировано тут работает только flock, а pid в случае падения демона может указывать на совершенно левый процесс, поэтому его дополнительно проверяют, но и это не даёт гарантий.

slovazap ★★★★★
( 01.02.18 21:18:16 MSK )
Ответ на: комментарий от slovazap 01.02.18 21:18:16 MSK

Не бывает такого чтобы две программы писали в один pid файл.

Я плохо написал вопрос. Про две программы я имел ввиду, условно, два типа программ. Ну или «есть два подхода работы с pid-файлам».

neschastnyjj86
( 01.02.18 21:24:47 MSK ) автор топика
Ответ на: комментарий от neschastnyjj86 01.02.18 21:03:00 MSK

Во-первых проще cat /path/to/pid отправить в килл или stdout в шелле, чем парсить ps. Во-вторых парсинг может ничего не дать.

cd a; nginx -c conf/nginx.conf
cd b; nginx -c conf/nginx.conf

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

Если ты так разбираешься в вопросе, что знаешь про linkname, и не тупой как пробка, то очевидно, что ты можешь догадаться почему так или эдак, и твой вопрос на самом деле звучит «как по**ать мозги на лоре». Зачем это делать — непонятно.

anonymous
( 01.02.18 21:37:03 MSK )
Ответ на: комментарий от anonymous 01.02.18 21:37:03 MSK

cat /path/to/pid отправить в килл или stdout в шелле, чем парсить ps

глупость несусветная, и кого ты так отправишь? вообще другой процесс? ахаха.

neschastnyjj86
( 01.02.18 22:02:30 MSK ) автор топика
Ответ на: комментарий от slovazap 01.02.18 21:18:16 MSK

Внешние программы могут прочитать pid из pid файла и использовать его чтобы послать демону

какому еще послать? что. им придется сверяться с АКТУАЛЬНЫМЫМ состоянием всё равно в любом случае. ты же сам понимаешь, что там другой процесс уже. зачем тогда этот номер нужен-то

neschastnyjj86
( 01.02.18 22:04:29 MSK ) автор топика

Не понимаю, как можно прочесть вопрос и не понимать о чем он. Неужели вы настолько тупые?

neschastnyjj86
( 02.02.18 13:09:49 MSK ) автор топика
Ответ на: комментарий от neschastnyjj86 01.02.18 22:04:29 MSK

Это бессвязный набор слов, потрудитесь задать вопрос по-человечески. Пока просто повторюсь как оно работает.

В pid файле pid демона. Кроме pid файла этот pid взять не от куда. Из таблицы процессов его взять нельзя, ибо инстансов демона может быть сколько угодно, и у каждого демона может быть сколько угодно процессов. Поэтому его берут из pid файла. Но он может быть протухшим, если демон упал. Поэтому его дополнительно проверяют. Да, это не 100% надёжно. Но в общем случае ничего лучше не придумали.

slovazap ★★★★★
( 02.02.18 13:19:11 MSK )

Как можно быть таким хамом и истеричкой на четвёртом десятке? Какой пример школьникам подаёшь? Срамота.

anonymous
( 02.02.18 14:26:26 MSK )
Ответ на: комментарий от slovazap 02.02.18 13:19:11 MSK

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

Из таблицы процессов его взять нельзя, ибо инстансов демона может быть сколько угодно

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

Поэтому его дополнительно проверяют.

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

neschastnyjj86
( 02.02.18 15:27:33 MSK ) автор топика
Ответ на: комментарий от anonymous 02.02.18 14:26:26 MSK

Как можно быть таким хамом и истеричкой на четвёртом десятке?

С сумоуверенным поверхностными людьми, с некомпетентными дебилами, с хамами разговор только такой.

C обуревшими псами обсуждающими мой возраст — тем более.

neschastnyjj86
( 02.02.18 15:30:13 MSK ) автор топика
Ответ на: комментарий от neschastnyjj86 02.02.18 15:30:13 MSK

C обуревшими псами обсуждающими мой возраст

Да ладно, не стыдись ты так. Некоторые и до старости ума не набираются. У тебя-то хоть ещё есть шанс исправиться. Дело поважнее твоих pid-файлов будет.

anonymous
( 02.02.18 16:49:19 MSK )
Ответ на: комментарий от anonymous 02.02.18 16:49:19 MSK

посмеялся над тобой дурачком

neschastnyjj86
( 02.02.18 16:52:46 MSK ) автор топика
Ответ на: комментарий от neschastnyjj86 02.02.18 16:52:46 MSK

Посмеялся и хорошо, но ума от этого у тебя, вижу, не прибавилось. Тебе ж уже намекали (модераторам: отковенная ложь, некомпетентность, упертость (комментарий)), что твой тон не располагает к конструктивной беседе. Тебя только что троллить от скуки и остаётся.

Так что покайся, принеси извинения всем, кого обозвал здесь словами несуразными, и, может, кто-то ещё да и продолжит этот тред. Хотя навряд ли.

anonymous
( 02.02.18 17:13:59 MSK )
Ответ на: комментарий от anonymous 02.02.18 17:13:59 MSK

может, кто-то ещё да и продолжит этот тред.
Хотя навряд ли

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

neschastnyjj86
( 02.02.18 17:43:03 MSK ) автор топика

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

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