Что такое программа демон

Иногда в разговорах программистов и системных администраторов можно услышать такие фразы: «А ты в курсе, что у тебя демон перестал работать?» или «Слушай, за это вообще другая служба отвечает, надо именно её запускать». Рассказываем, что это значит.

Что такое демоны

Демон (daemon) — это программа в UNIX-системах, которая постоянно работает фоном и выполняет какую-то одну свою задачу. UNIX-системы — это сам Unix, Linux, BSD, Solaris, MacOS и ещё много других. Про Юникс мы расскажем отдельно.

Чаще всего демоны запускаются при старте системы и работают всё время, пока работает компьютер или сервер.

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

Что такое службы

Службы — это то же самое, что и демоны, только в Windows.

КАК ПОЛЬЗОВАТЬСЯ DAEMON TOOLS? УСТАНОВКА И НАСТРОЙКА ДЕМОН ТУЛС

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

Зачем нужны демоны и службы

Каждая из таких программ отвечает за свой участок работ:

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

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

Агенты загрузки и объекты автозапуска

Часто демонов путают с Launch Agents и Startup Items (на MacOS и Windows соответственно). Это общее название программ, которые запускаются при запуске компьютера и входе в систему. Но, в отличие от демонов, у этих агентов может быть графический интерфейс. Например, если при входе в систему автоматически запускается торрент-клиент или приложение для VPN, то это агенты загрузки. Вы можете ими пользоваться.

А демоны невидимы и просто делают так, чтобы компьютер работал — порты пробрасывались, сокеты открывались, данные туда-сюда ходили, жёсткие диски были видны и т. д. Можно сказать, что агенты загрузки — это ваши полезные привычки; а демоны — это ваши инстинкты.

Уровни доступа и разрешения

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

Написание демона, часть первая. Создание скрипта для демонизации.

Демоны в UNIX-системах обычно запускаются на уровне системных и служебных пользователей, то есть живут над обычными пользователями, которые садятся и вводят свой логин и пароль. Вы ещё не залогинились, а демоны уже шуршат портами.

А вот когда вы вошли, то и ваш скрипт автозапуска при логине может запустить других демонов. Они уже, в свою очередь, запускаются на уровне вашего пользователя, и им в системе можно ровно то, что можно вам.

Антивирусы — это демоны?

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

Можно ли сделать собственного демона?

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

Например, если у вас на предприятии используется ультрасекретная система выключения экрана при отводе глаз, то можно написать демона: он будет через камеру следить за глазами и чуть что — выключать монитор. И это будет работать вне зависимости от того, зашёл пользователь в систему или просто мимо проходил.

Почему такое название?

Слово заимствовано из латинского daemon, а оно, в свою очередь, из древнегреческого. И у тех и у других слово означало любого духа: злого, доброго, главное — сверхъестественного. Программы-демоны ровно так и работают: на фоне и незаметно.

В русский язык слово «демон» пришло из греческого именно в значении «злой дух», а в русский айтишный — из английского. Никакой чертовщины в айтишных демонах не предусмотрено.

Источник: dzen.ru

Процесс разработки и тестирования демонов

Сегодня мы поговорим о «низкоуровневых» кирпичиках нашего проекта — о демонах.

Определение из Википедии:

«де́мон — компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем».

Хоть это и не очевидно, но практически весь функционал сайта во многом зависит от работы этих программ. Игра в “Знакомства”, поиск новых лиц, центр внимания, обмен сообщениями, статусы, геолокация и многие другие вещи завязаны на тот или иной демон. Так что можно сказать, что они помогают людям по всему миру общаться и находить новые знакомства. Одновременно на сайте могут работать и взаимодействовать между собой несколько десятков демонов. Их корректное поведение является очень важной задачей, поэтому мы решили покрывать основной функционал демонов автотестами.

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

В качестве VCS у нас используется Git, для непрерывной интеграции — TeamCity, а в роли баг-трекера выступает JIRA. Для тестирования мы используем PHPUnit. Разработка демонов, как и остального сайта, ведется по принципу «фича ― ветка». Для того чтобы понять, что это, мы рассмотрим проекции нашего flow на Git и на JIRA.

Git flow

Работу в Git схематично можно описать картинкой:

Для работы над задачей от master-ветки форкают отдельную ветку task_n, в которой ведется вся разработка. Затем эта ветка и, возможно, несколько других сливаются в так называемый branch build_n.n.n (или просто билд), и только он уже попадает в master.

JIRA flow

Процесс в JIRA сложнее и включает в себя больше этапов. На рисунке ниже изображены основные из них.

Open -> In progress
Статус Open говорит о том, что задача есть, но к ней еще не приступили. Когда программист начинает работать и отправляет первые изменения на наш git-сервер (там появится ветка, содержащая в имени task_n, идентификатор в JIRA), происходит несколько событий. Во-первых, статус задачи становится In progress, а во-вторых, наша TeamCity создает отдельную сборку для этой ветки, которая запускается каждый раз при новом «пуше» разработчика. Благодаря стараниям релиз-инженеров и разработчиков, артефакты из сборки скопируются на машины нашей среды разработки, после этого запустятся все регрессионные тесты, а результат прогона отобразится в веб-интерфейсе TeamCity. Когда разработчик посчитает, что он закончил работу над задачей, он переводит тикет с ней в статус On Review.

On Review
Здесь задача проходит доскональное изучение со стороны коллеги. Если его взгляд не нашел к чему придраться, тикет переводится в статус In Branch QA.

In Branch QA
На этом этапе задача попадает к тестировщику. Он первым делом смотрит на результат прогона регрессионных тестов — вдруг какие-то из них теперь не проходят. В этом случае есть два варианта: либо все нормально, это результат нового поведения и надо актуализировать регрессионные тесты, либо демон работает не так, как ожидается, тогда задача возвращается к разработчику. Если необходима доработка тестов, QA-инженер берется за дело вплотную. Он покрывает новое поведение демона тестами, попутно исправляя старые, если это необходимо.

To Merge -> In Build
Когда разработчик и тестировщик считают, что сборка из ветки task_n работает стабильно и ожидаемо, в JIRA нажимается кнопка To Merge. В этот момент TeamCity «мержит» ветку разработчика в ветку build_n.n.n и запускает его сборку. Задача снова попадает к тестировщику, но уже со статусом In Build.

Дело в том, что при мерже могут возникнуть неожиданные конфликты: пока ветка была на тестировании, в билдовую могли добавиться несовместимые изменения. При возникновении такой ситуации задача переводится на программиста для ручного мержа в билд. Другой проблемой могут быть падающие регрессионные тесты или, в самом плохом случае, невозможность запустить демон. Это решается откатом задачи из билдовой ветки с возвращением тикета разработчику. Но если нужны незначительные изменения для решения проблемы, то задача остается и появляется патч в самом билде.
Когда тесты проходят, а демон стабилен, QA-инженер присваивает задаче статус In Build OK и она возвращается к разработчику. Билд демона с измененным поведением становится основным в среде разработки devel и проходит испытание боем.

In Build OK -> On Production
В какой-то момент в билдовой ветке накапливается много нужных изменений или появляются критически важные задачи, и разработчик решает, что пора двигать билд на продакшн. Нажимается кнопка Finish Build, и новая версия демона, благодаря нашим доблестным админам, начинает работать на машинах, отвечающих за настоящую работу нашего сайта. В это время билд мержится в master-ветку и создается новый билд с именем build_m.m.m, в который будут попадать все новые изменения. Ну, а тикету программиста поставят статус On Production.

Объединив две проекции всего процесса разработки, получим цикл, показанный ниже.

Подробнее о наших процессах разработки и плотной интеграции JIRA, TeamCity и Git можно прочитать в наших статьях тут, тут и тут.

Выполнение автотестов

Объект тестирования
Для начала давайте определимся с тем, что именно мы тестируем.
В нашем случае программа в общем виде представляет из себя некий бинарный файл, запускающийся из терминала. В качестве аргументов ему могут быть переданы различные параметры, влияющие на его работу: конфигурационные файлы («конфиги»), порты, лог-файлы, папки со скриптами и т.д. Чаще всего это как минимум конфиг, и строка запуска в этом случае будет выглядеть так:

>> daemon_name -c daemon_config

После запуска демон ожидает подключения на нескольких портах (сокет-файлах), по которым происходит общение с внешним миром. Формат может быть разным, начиная от текста или JSON’а и заканчивая protobuf’ом. Обычно поддерживается сразу пара из них. Также у некоторых демонов есть возможность сохранять свои данные на диск, а потом загружать их при запуске.

Для разработки в основном используется C и C++, но с недавних пор добавились Golang и Lua.

В общем виде выполнение автотестов можно разбить на несколько этапов:

1. Подготовка тестового окружения.
2. Запуск и исполнение тестов.
3. Чистка тестового окружения.

>> phpunit daemon_tests/test.php —option=value

Подготовка тестового окружения
После запуска тестов сначала исполняется та часть кода, которая определена в конструкторах setUpBeforeClass и setUp. Как раз на данном этапе и подготавливается окружение: сначала читаются параметры запуска, о которых мы расскажем отдельно, потом выбирается нужная версия бинарного файла, создаются временные папки, конфиги и различные файлы, которые могут понадобиться для работы, а также подготавливаются БД, если они нужны. Все создаваемые объекты содержат уникальный идентификатор в имени, который выбирается один раз в конструкторе и дальше используется повсеместно. Это позволяет избежать конфликта при одновременном запуске тестов у нескольких разработчиков и тестировщиков.

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

Помните, я говорил, что демон ждет подключения на портах? Последним шагом является создание коннектов к ним и проверка готовности демона к общению. Если все хорошо, то запускаются непосредственно тесты.

Запуск и исполнение
Большинство тестов можно описать алгоритмом:

В качестве send request может выступать один или несколько запросов, приводящих к какому-то определенному состоянию. Действия внутри get response — получение ответа, чтение записей в БД, чтение файла. Под assert же подразумевается большой спектр действий: это и валидация ответа, и оценка состояния демона, и проверка данных, пришедших в соседние демоны, и сравнение записей в БД, и даже проверка создания снапшотов с правильными данными.

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

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

Чистка тестового окружения
Как бы не закончились тесты, после себя нужно чистить. В первую очередь мы закрываем коннекты, останавливаем демон и всех связанных с ним моков или соседних демонов. Затем удаляются все созданные во время тестов файлы и папки, если они не нужны, и подчищаются БД.

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

На весь описанный процесс тестирования накладывается определенная особенность — распределение по разным машинам. Обычным сценарием сейчас является запуск тестов на одном сервере, а старт демона на другом. Ну, или на другом сервере в контейнере docker’а.

• branch. Сюда передается имя тикета в JIRA, в рамках которого проводились работы над демоном. Тесты будут использовать сборку бинарного файла именно этой задачи;
• settings. Сюда передается путь до ini-файла, в котором прописаны специфичные для тестов вещи. Это может быть версия билда, путь до дефолтного конфига, пользователь, от которого запускается демон, расположение необходимых файлов;
• debug. Если этот флаг передан, тесты работают в режиме отладки. Для нас это значит, что имена временных файлов и папок будут удобочитаемы, что позволяет их легко выделять из остальных. Также все файлы, создаваемые во время прогона тестов, не будут удаляться — это позволяет при необходимости воспроизводить падающие тесты;
• script. Когда этот флаг присутствует, во время выполнения теста генерируются php-скрипт, повторяющий все действия теста, до момент его завершение или срабатывание ассерта. Этот скрипт полностью самостоятельный, что помогает при дебаге демона.

Константин Карпов, QA инженер

• badoo
• Баду
• разработка демонов
• тестирование демонов
• тестирование
• QA
• автоматизация тестирования
• docker

Источник: habr.com

Как работают демоны, процесс Init и как у процессов рождаются потомки — изучаем основы Unix

Если вы когда-нибудь работали c Unix-системами, то наверняка слышали термин «демон». В этой статье я хочу объяснить, что это за демоны и как они работают, тем более что их название заставляет думать, что это что-то плохое.

Вообще демон — это фоновый процесс, который не привязан к терминалу, в котором был запущен. Но как они создаются, как они связаны с другими процессами, как они работают? Об этом мы и поговорим, но сперва давайте узнаем, как работает процесс init и как происходит рождение новых процессов.

Как работает процесс Init

Для начала поговорим о процессе init, также известном как PID 1 (поскольку его ID всегда равен 1). Это процесс создаётся сразу при запуске системы, то есть все другие процессы являются его потомками.

Обычно init запускается, когда ядро вызывает конкретный файл, обычно находящийся по адресу /etc/rc или /etc/inittab. Процесс устанавливает путь, проверяет файловую систему, инициализирует серийные порты, задаёт время и т.д. В последнюю очередь он запускает все необходимые фоновые процессы — в виде демонов.

Все демоны обычно расположены в папке /etc/init.d/; принято оканчивать имена демонов на букву d (например, httpd, sshd, mysqld и т.п.), поэтому вы можете подумать, что директория названа так по этому же принципу, но на самом деле существует соглашение об именовании папок, содержащих конфигурационные файлы, именем с суффиксом .d. Итак, init запускает демонов, но мы так и не выяснили, как это происходит. Процесс init запускает демонов, создавая свои ответвления для запуска новых процессов.

Как работает разветвление процессов

Единственный способ создать новый процесс в Unix — скопировать существующий. Этот метод, известный как разветвление или форкинг, включает в себя создание копии процесса в виде потомка и системный вызов exec для запуска новой программы. Мы использовали слово «форкинг», поскольку fork — это реальный метод C в стандартной библиотеке Unix, который создаёт новые процессы именно таким образом. Процесс, вызывающий команду fork, считается родительским по отношению к созданному. Процесс-потомок почти полностью совпадает с родительским: отличаются лишь ID, родительские ID и некоторые другие моменты.

Главный администратор Unix Открытие , Москва, можно удалённо , По итогам собеседования

В современных дистрибутивах Unix и Linux процессы можно создавать и другими способами (например, при помощи posix_spawn), но большая часть процессов создаётся именно так.

Теперь, когда вы узнали о традиционном значении термина «fork», становится понятно, почему такое же понятие используется на GitHub. Но я отвлекся — вернемся к нашим демонам!

Как работают демоны

Схема демона Максвелла

Прежде чем мы углубимся в работу демонов, давайте выясним, откуда взялось это название. Термин «демон» возник из Project MAC, который в свою очередь получил своё имя от демона Максвелла — вымышленного существа из мысленного эксперимента, которое постянно сортирует молекулы. Само слово демон происходит от греческого daemon, являющегося сверхъестественным существом, которое постоянно работает на заднем плане и не является добрым или злым (в отличие от обычного современного значения). То есть, термин «демон» (в смысле Unix-процесса) на самом деле произошёл от вымышленного сверхъестественного существа.

Демоны — это фоновые процессы, работающие отдельно от терминала и почти всегда созданные процессом init; обычно они занимаются такими вещами, как сетевые запросы, работой аппаратного обеспечения и прочими заданиями типа «жди и смотри».

Демоны появляются двумя способами. Их может создать процесс init, либо же они возникают в следущей ситуации: процесс создаёт своего потомка и тут же завершается. Первый случай ясен, но что происходит во втором: как процесс init становится родительским для этих демонов?

Когда вы создаёте процесс-потомок и тут же «убиваете» его родителя, потомок становится процессом-сиротой (не стоит путать с процессом-зомби, например, потомком, который был завершен, но всё ещё ждёт, когда родитель прочтёт его exit-статус). По умолчанию, если процесс становится сиротой, то его «приёмным» родителем становится init. Вот и всё, что делает демонов уникальными!

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

Следите за новыми постами по любимым темам
Подпишитесь на интересующие вас теги, чтобы следить за новыми постами и быть в курсе событий.
Поделиться
Реклама на Tproger: найдем для вас разработчиков нужного стека и уровня.
Курс «Основы программирования на Python»
Старт 3 июля, 2 месяца, онлайн, от 6664 до 19 990 ₽ в месяц

Курс «Django — разработка веб-приложений»
Старт 10 июля, 3 месяца, онлайн, от 6664 до 19 990 ₽ в месяц

Что думаете?

Комментирую от имени компании
Показать все комментарии
Фотография
Обсуждают сейчас
Увеличиваем конверсию в собеседования бесплатно, онлайн, без регистрации
19 минут назад

У вас отличный опыт.
Карьерный путь: из 1C специалиста в Тимлида разработки на Python
5 часов назад

Источник: tproger.ru