Термин daemon, или демон, произошёл от слова, которое в древнегреческой мифологии означало некую нематериальную сущность, оказывающую влияние на мир людей.
В контексте информатики, особенно в UNIX-подобных операционных системах, daemon — это фоновый процесс, работающий без прямого взаимодействия с пользователем. Демон не зависит от терминала или пользовательского интерфейса и обычно запускается сразу при старте системы, либо при определенных условиях.
cloud
Основная функция демона — предоставлять определённые сервисы другим процессам или самим пользователям. Например, daemon может слушать сетевые порты в ожидании подключения, следить за событиями в системе и запускать действия, когда выполняются определённые условия. Или управлять расписанием работ (cron
), отправкой почты (sendmail
) и другими задачами.
В Windows практически аналогичными процессами являются службы (services
). Разница между демонами в UNIX/Linux и службами в Windows в основном сводится к тому, как они запускаются, регистрируются, управляются и конфигурируются в контексте конкретной операционной системы. Но назначение одинаковое: обеспечить непрерывную работу некоторых фоновых функций или сервисов.
Работает в фоновом режиме.
Пользователь обычно не видит интерфейс daemon; он не пишет сообщения в стандартный вывод (или перенаправляет их в лог), не запрашивает ввода с клавиатуры.
Автономность.
Daemon запускается либо при загрузке системы, либо когда его вызывает отдельная служба инициализации (например, systemd
), либо когда пользователь явно запускает его вручную (через скрипт, cron
и т. п.).
Бессрочное исполнение.
В идеальном случае daemon не должен завершаться, если не произошла критическая ошибка или не поступила явная команда на остановку.
Изоляция.
Обычно daemon работает под отдельной учётной записью (своим пользователем и группой), чтобы не было лишних привилегий и чтобы каждая служба была максимально безопасна и легко управляема.
Логирование.
Вместо стандартных потоков ввода/вывода daemon записывает информацию о своей работе в лог-файлы, системный лог (journald
, syslog
и т. д.), что помогает при диагностике.
В Linux исторически сложилось, что практически все системные фоновые задачи реализованы в виде демонов. В состав ОС уже входят десятки демонов, каждый из которых отвечает за свою узконаправленную функцию. Рассмотрим основные примеры:
sshd (Secure Shell Daemon)
Daemon слушает порт 22 (по умолчанию) и позволяет пользователям удалённо подключаться к серверу по зашифрованному протоколу SSH. Без запущенного sshd
обеспечить удаленную текстовую консоль практически невозможно.
cron
Демон планировщика заданий. Он регулярно проверяет списки заданий (crontab
) и запускает команды или скрипты в соответствии с расписанием. Это может быть очистка логов раз в неделю, отправка отчетов, проверка состояния системы — что угодно, что хочется автоматизировать по расписанию.
syslogd / rsyslog / journald
Демоны системного логирования, которые собирают сообщения от ядра, системных утилит, других daemon и приложений, после чего сохраняют их либо в файлы, либо в систему журналирования (journal
). Это дает возможность централизованно собирать и анализировать сообщения и ошибки.
NetworkManager или Wicd
Демоны управления сетевыми настройками, позволяющие автоматизировать подключение к проводным и беспроводным сетям, переключение между ними, настройку VPN и прочие сетевые задачи.
Все эти демоны запускаются при старте системы, регистрируются в системном менеджере служб (например, systemd
). Они работают в течение всего времени до выключения сервера или перезагрузки. При этом пользователь может взаимодействовать с демоном только опосредованно — через конфигурационные файлы, команды в терминале (service
, systemctl
), или через сетевые запросы (если daemon предоставляет HTTP/S, SSH или другой сетевой интерфейс).
Для реализации демона нужно реализовать следующие шаги:
Ответвление процесса (fork).
Процесс-родитель запускает fork()
, и в дочернем процессе мы продолжаем выполнение кода будущего демона.
Отсоединение от управляющего терминала (setsid).
Чтобы избежать влияния пользователя, который может случайно закрыть терминал или послать сигнал, демон часто вызывает setsid()
, создавая новую сессию и делая себя лидером этого daemon.
Закрытие стандартных дескрипторов ввода/вывода.
Демон не должен писать в стандартный вывод или ожидать чтения с клавиатуры, поэтому закрывают (или перенаправляют в файл/лог) stdin
, stdout
и stderr
.
Перенаправление сигналов и ведение логов.
Чтобы корректно завершать работу или перезагружать конфигурацию, daemon обрабатывает сигналы (SIGTERM
, SIGHUP
и т. д.). Также процессу важно вести логи, обычно через syslog
или через файлы.
Основной цикл.
После инициализации daemon запускает основной цикл: ожидает события, обрабатывает их, снова ожидает и так далее, пока не будет получен сигнал на остановку.
Рассмотрим организацию daemon на примере облачного сервера Timeweb Cloud с ОС Ubuntu 22.04.
Вставьте код на языке C в файл mydaemon.c
:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <syslog.h>
int main() {
// Открываем syslog
openlog("mydaemon", LOG_PID, LOG_DAEMON);
syslog(LOG_NOTICE, "Демон запущен");
// Основной бесконечный цикл
while (1) {
// Ваши фоновые задачи: мониторинг, обработка очередей, и т.д.
syslog(LOG_NOTICE, "Выполнение задачи...");
sleep(60);
}
// Если когда-то выйдем из цикла:
syslog(LOG_NOTICE, "Демон остановлен");
closelog();
return 0;
}
Скомпилируйте программу с помощью компилятора gcc
.
Если его нет в системе, обновите пакеты:
sudo apt update && sudo apt upgrade
И установите компилятор:
sudo apt install gcc
Для запуска компиляции:
gcc mydaemon.c -o mydaemon
Перенесите полученный исполняемый файл в директорию /usr/local/bin/
.
Традиционно служебные утилиты помещают в эту директорию, чтобы гарантировать удобство доступа и соответствие стандартам размещения исполняемых файлов.
mv mydaemon /usr/local/bin/mydaemon
В Linux с systemd
каждый сервис (daemon) описывается в особом unit-файле с расширением .service
. Создайте новый файл с именем, например, mydaemon.service
:
sudo nano /etc/systemd/system/mydaemon.service
Вставьте следующее содержимое:
[Unit]
Description=My Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mydaemon
Restart=on-failure
[Install]
WantedBy=multi-user.target
Разберём основные поля:
[Unit]
Description — произвольное описание, которое будет видно при выполнении команды systemctl status mydaemon
.
After — гарантирует, что daemon запустится после указанных служб или таргетов (например, network.target
даёт уверенность, что сеть уже поднята).
[Service]
Type=simple
означает, что процесс «один к одному» совпадает с самим daemon. Если ваш daemon не разветвляется дополнительно, это наиболее простой вариант.
PIDFile
— обязателен при Type=forking
, потому что systemd должен знать, какой процесс считать «главным».
ExecStart
— путь к исполняемому файлу daemon.
Restart=on-failure
— настройка, указывающая systemd
автоматически перезапускать daemon, если тот завершился с ошибкой.
[Install]
WantedBy=multi-user.target
говорит, что служба должна запускаться в обычной многопользовательской среде (уровне). Это типовое значение для постоянных сервисов.
Запустите daemon:
sudo systemctl daemon-reload # обновляет конфигурацию systemd
sudo systemctl start mydaemon # запускает указанный сервис вручную
sudo systemctl status mydaemon # показывает статус сервиса mydaemon
Статус daemon должен быть active
:
В логах будет строка о запуске демона, которая вызвана нашей программой.
journalctl -u mydaemon.service -e
Веб-серверы
Их задача — слушать сетевой порт (80 или 443), принимать HTTP/HTTPS-запросы, формировать ответ (HTML-страницу, JSON-данные и т. п.) и возвращать результат клиенту. В большинстве случаев веб-сервер запускается при старте системы и не останавливается, пока сервер не будет выключен или не будет выполнена командная остановка (например, systemctl stop nginx
).
Демоны баз данных
MySQL/MariaDB, PostgreSQL, MongoDB — все они также являются демонами. Запускаются вместе с системой, продолжают работать в фоновом режиме, принимая запросы от клиентских приложений или веб-сервисов. Эти демоны обычно ведут логи, позволяют настраивать конфигурацию через файлы и управляются через специальные утилиты (либо тот же systemd
).
Планировщики заданий (cron, atd)
Daemon cron проверяет таблицу расписаний (crontab
) и запускает программы в указанное пользователем время или периодичность. Таким образом можно автоматизировать резервное копирование, обновление системы, мониторинг состояния и многие другие рутинные задачи.
atd
— похожий daemon, но запускает задания однократно в заданный момент времени (в отличие от cron
, который работает по расписанию).
Службы доступа и управления (sshd, xrdp)
sshd
(Secure Shell Daemon) обеспечивает удалённый доступ по SSH-протоколу.
xrdp
позволяет подключаться к удалённому рабочему столу через протокол RDP, выступая в качестве демона, который слушает сетевые соединения на определённом порту.
Daemon системы инициализации (systemd, init, Upstart)
На современных системах роль «главного демона» выполняет systemd
(вместо старой схемы SysV init
). Systemd запускается первым после ядра, управляет остальными службами и процессами, запускает их параллельно, обрабатывает зависимости. Попросту говоря, systemd
сам является демоном, который «руководит» всеми остальными в системе.
Автоматизация
Демоны позволяют автоматизировать поведение системы: от реакции на сетевые запросы до планирования периодических задач, не требуя участия пользователя.
Изоляция
Запуск под отдельными учетными данными (пользователь/группа) и закрытие терминалов существенно повышают безопасность, поскольку ограничивают потенциальный вред при взломе daemon.
Непрерывный режим работы
Daemon может непрерывно обслуживать запросы (например, веб-сервер) и не прекращать работу при разлогинивании пользователя или закрытии консоли.
Управляемость
В Linux обычно есть системные механизмы (systemd
, init-скрипты), позволяющие централизованно управлять всеми демонами: запускать, останавливать, перезапускать, отслеживать логи.
Сложность отладки
Поскольку демон работает в фоновом режиме и не имеет прямого вывода в консоль, отладка требует ведения логов и более сложной настройки (включая полноценное логирование, отладочные ключи, трассировку).
Потенциальные риски безопасности
Если daemon запускается с повышенными привилегиями (root
), его уязвимости могут поставить под угрозу всю систему. Поэтому рекомендуется запускать от имени ограниченного пользователя.
Управление зависимостями
Не все демоны способны справиться, если требуется, например, доступ к сети, а сеть ещё не поднята. Современные системы инициализации помогают решать эту проблему, но в классических SysV init-скриптах подобные ситуации вызывали трудности.
Повышенный расход ресурсов
Любой постоянно работающий фоновой процесс потребляет системные ресурсы (оперативную память, процессорное время). Если daemon слишком много, это может сказаться на производительности, особенно в системах с ограниченными ресурсами.
Подготовили для вас выгодные тарифы на облачные серверы
Демоны занимают центральное место в архитектуре UNIX-подобных операционных систем, обеспечивая широкие возможности по автоматизации и предоставлению фоновых сервисов. Благодаря им администраторы могут гибко настраивать работу сети, периодических задач, журналирования, систем безопасности и множества других компонентов. Написание собственного демона требует понимания процессов, сигналов, системных вызовов, а также аккуратной работы с логированием и безопасностью.
Современные системы инициализации (особенно systemd
) упростили управление и логику запуска демонов, сделав процессы по созданию собственных служб более гибкими и формализованными. Однако это по-прежнему сложная область, требующая аккуратного подхода к проектированию, отладке и поддержке.