Прежде чем писать настоящих демонов попробуем начать с чего-то попроще.

Надо понимать, что демон — это программа которая работает потенциально бесконечно долго и ждет указаний.

Возможно самый близкий вам пример демона будет СУБД. То есть это некий сервис, у которого есть набор файлов, которыми он управляет, а если его хорошо попросить он с вами еще и какой-то информацией поделится. Просится оно через ваш любимый sql.

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

Писать будем снова на C#. Тут я не буду все расписывать. А просто расскажу вам про те инструменты, которые понадобятся для работы.

Первое что нам понадобится это механизм мониторинга изменений файлов. В линуксе такой механизм реализуется через модуль ядра inotify. А в C# есть замечательный класс который называется FileSystemWatcher, который как раз есть обертка вокруг этого самого inotify

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

using System;
using System.IO;

namespace daemon
{
    class Program
    {
        static void Main(string[] args)
        {
            // указываем папку для отслеживания
            using var watcher = new FileSystemWatcher(@"/home/m");
        
            // чего мониторим
            watcher.NotifyFilter = NotifyFilters.Attributes
                 | NotifyFilters.CreationTime
                 | NotifyFilters.DirectoryName
                 | NotifyFilters.FileName
                 | NotifyFilters.LastAccess
                 | NotifyFilters.LastWrite
                 | NotifyFilters.Security
                 | NotifyFilters.Size;
        
            // конкретный файл мониторим через Filter
            watcher.Filter = "file.txt"; 
            
            // реакция на изменение
            watcher.Changed += OnChanged;
            watcher.EnableRaisingEvents = true; // ожидаем что watch будет генерить события
        
            // watcher создаст отдельный поток в котором будет обрабатываться события 
            // пока юзер на выйдет из программы нажав Enter
            Console.WriteLine("Нажмите Enter для выхода");
            Console.ReadLine();
        }

        private static void OnChanged(object sender, FileSystemEventArgs e)
        {
            if (e.ChangeType != WatcherChangeTypes.Changed)
            {
                return;
            }
            Console.WriteLine($"Изменился: {e.FullPath}");
        }
    }
}

Теперь если в одной консоли запустить программу а в другой писать что-то в файл. Наш микродемон будет реагировать на изменения:

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

Чтобы выполнять консольные команды прямо из C#, вам потребуется класс System.Diagnostics.Process работают с ним так

using System;
using System.Diagnostics;

namespace daemon
{
    class Program
    {
        static void Main(string[] args)
        {
            Process proc = new System.Diagnostics.Process ();
            proc.StartInfo.FileName = "apt"; // название утилиты или скрипта который будем запускать
            proc.StartInfo.Arguments = "show git"; // параметры для скрипта
            proc.StartInfo.UseShellExecute = false; // не использовать оболочку bash
            proc.StartInfo.RedirectStandardOutput = true; // для перехвата входного потока
            proc.Start (); // запускаем

            while (!proc.StandardOutput.EndOfStream) { // перехватываем вывод
                Console.WriteLine (proc.StandardOutput.ReadLine ());
            }
        }
    }
}

в ответ он просто напишет то что перехватил из программы apt

И так в прошлом задании мы сделали консольное приложение которое мониторит файлик и реагирует на его изменения.

У нас есть небольшое неудобство, заключающееся в том, что нам приходится запускать наше приложение вручную.

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

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

• systemctl – для непосредственного управления сервисами (перезапуск, остановка, проверка статусов)
• journalctl – для просмотре логов

Например, можно запустить команду systemctl list-units --type=service и увидеть список всех сервисов доступных в системе

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

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

sudo systemctl cat ИМЯ_СЕРВИСА

например можно глянуть сервис который ответственен за общение VirtualBox и нашего линукса

sudo systemctl cat vboxadd.service

В выводе видим две наиболее интересных строчки. Первая это путь к файлу в котором содержится описание сервиса /lib/systemd/system/vboxadd.service. Скоро мы сделаем свой такой.

И вторая это строчка, начинающаяся с ExecStart которая собственно и указывает которую команду надо запустить при старте сервиса.

Можно глянуть кстати, что лежит в папке /lib/systemd/system и увидеть, что там действительно есть такой файлик и еще куча других

ls /lib/systemd/system

каждый отвечает за какой-то свой сервис

Мы можем отредактировать каждый файлик либо прямо через nano (или какой-то у вас любимый редактор), типа

sudo nano /lib/systemd/system/vboxadd.service

либо используя systemctl, вот так

sudo systemctl edit --full vboxadd.service

Регистрация сервиса

И так, чтобы наш сервис подключить к супервизору создадим файлик my_daemon.service:

и теперь опишем в него сервис

[Unit]
Description=Заклинатель книг  # название сервиса

[Service]
User=m  # под каким юзером запускать
# рабочая директория, в ней будет искаться config.txt
WorkingDirectory=/home/m/projects/daemon/bin/Debug/net7.0 
# путь к скомпилированному файлу
ExecStart=/home/m/projects/daemon/bin/Debug/net7.0/daemon -f config.txt

[Install]
WantedBy=multi-user.target # хотим, чтобы запускалось при запуске системы

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

Теперь нам надо подключить этот файлик к супервизору.

Сначала надо положить его в папку /etc/systemd/system, чтобы проще было редактировать мы просто создадим ссылку на наш файл вот так:

sudo ln -s $PWD/my_daemon.service /etc/systemd/system

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

Переменная $PWD как раз хранит полный путь текущей папки.

теперь надо перегрузить кеш сервисов

sudo systemctl daemon-reload

моя программа выглядит вот так

using System;
using System.IO;
using System.Runtime.InteropServices;

namespace daemon
{
    class Program
    {
        static void Main(string[] args)
        {
            using var watcher = new FileSystemWatcher(@"/home/m");
            watcher.NotifyFilter = NotifyFilters.LastWrite;
            watcher.Filter = "file.txt"; 

            watcher.Changed += OnChanged;
            watcher.EnableRaisingEvents = true;

            Console.WriteLine("Нажмите Enter для выхода");
            Console.ReadLine();
        }

        private static void OnChanged(object sender, FileSystemEventArgs e)
        {
            if (e.ChangeType != WatcherChangeTypes.Changed)
            {
                return;
            }
            Console.WriteLine($"Изменился: {e.FullPath}");
        }
    }
}

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

Момент истины, запускаем наш сервис:

sudo systemctl start my_daemon.service

теперь попробуем узнать статус нашего сервиса

sudo systemctl status my_daemon.service

получится что-то такое

то есть наш процесс успешно отработал, не стал ждать ввода от пользователя и успешно завершился. Его состояние inactive, то бишь не работает.

А мы вроде как хотели, чтобы он там сидел всякие файлы мониторил.

Реализуем бесконечный цикл

Короче, дело в том, что сервисам недоступен поток ввода, поэтому программа не останавливается в ожидании ввода, а просто завершает свою работу.

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

using System;
using System.IO;
using System.Runtime.InteropServices;
using System.Threading; # работа с потоками

namespace daemon
{
    class Program
    {
        static void Main(string[] args)
        {
            using var watcher = new FileSystemWatcher(@"/home/m");
            watcher.NotifyFilter = NotifyFilters.LastWrite;
            watcher.Filter = "file.txt"; 

            watcher.Changed += OnChanged;
            watcher.EnableRaisingEvents = true;

            while(true) {
                Thread.Sleep(2000);
                Console.WriteLine("Мониторю");
            }

            //Console.WriteLine("Нажмите Enter для выхода");
            //Console.ReadLine();
        }

        private static void OnChanged(object sender, FileSystemEventArgs e)
        {
            if (e.ChangeType != WatcherChangeTypes.Changed)
            {
                return;
            }
            Console.WriteLine($"Изменился: {e.FullPath}");
        }
    }
}

собираем

dotnet build

и запускаем сервис по новой

sudo systemctl start my_daemon.service

Во, теперь процесс в состоянии running и начинает писать в лог. Можно даже чего-нибудь в файл записать и увидеть, как сервис на это реагирует

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

Смотрим лог

Чтобы посмотреть полный лог, надо воспользоваться утилитой journalctl.

Для просмотра лога по своему юниту надо ввести вот такую команду

journalctl -u my_daemon.service

чтобы выйти из лога нажмите q

если хочется смотреть лог в режиме реального времени, то можно добавит флаг -f (–follow)

journalctl -u my_daemon.service -f

кстати, чтобы остановить процесс воспользуетесь командой

sudo systemctl stop my_daemon.service

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

И еще один важный момент чтобы ваш демон действительно запустился при перезапуске системы надо активировать сервис командой enable

sudo systemctl enable my_daemon.service

можно попробовать перезапустить систему и проверить что сервис действительно перезапустился.

И так у нас сейчас есть сервис он же демон, который работает потенциально бесконечно.

Но что будет, если по какой-то причине в коде произойдет непредвиденная ситуация и произойдет исключение.

Давайте попробуем смоделировать такую ситуацию.

Генерим ошибку

Я добавлю в событие генерацию ошибки. Так как OnChanged на самом деле вызывается асинхронно то я не могу просто взять и сгенерить ошибку в нем. Типа так:

private static void OnChanged(object sender, FileSystemEventArgs e)
{
    throw new Exception("Падаю =ООО"); // добавил ошибку
    
    Console.WriteLine($"Изменился: {e.FullPath}");
}

мне придется немного смухлевать и добавить поле, которое указывает что ошибка произошла, и просто проверять ее в цикле:

class Program
{
    static bool errorRaised = false; // добавил поле, которое будет уходить в true при возникновении ошибки

    static int Main(string[] args)
    {
        // ...

        while(true) {
            Thread.Sleep(2000);
            Console.WriteLine("Мониторю");
            
            // проверяю errorRaised и если оно true, то кидаю ошибку
            if (errorRaised) {
                throw new Exception("Падаю =ООО"); 
            }
        }    
    }

    private static void OnChanged(object sender, FileSystemEventArgs e)
    {
        errorRaised = true; // тут меняю значение на true чтобы сгенерить ошибку
        Console.WriteLine($"Изменился: {e.FullPath}");
    }
}

перебилдиваем и перезапускаем

dotnet build
sudo systemctl restart my_daemon.service

запускаем журнал

journalctl -u my_daemon.service -f

и в параллельной консольке пробуем чего-нибудь вписать в файл

как видим процесс умирает с концами и перестает мониторить.

Подключаем автоперезапуск

Одной из важнейших задач супервизора является оживление упавших процессов.

В общем, чтобы наш процесс после умирания сразу восстанавливался необходимо добавить в описание сервиса (файл my_daemon.service) строчку

[Unit]
Description=Заклинатель книг

[Service]
User=m
Restart=on-failure # вот эту
WorkingDirectory=/home/m/projects/daemon/bin/Debug/net5.0
ExecStart=/home/m/projects/daemon/bin/Debug/net5.0/daemon -f config.txt

[Install]
WantedBy=multi-user.target

полный список допустимых значений такой

вообще почитать про разные параметры для сервиса можно тут

man systemd.service

после того как подправите файлик надо обновить кэш systemd и перезапустить сервис

sudo systemctl daemon-reload
sudo systemctl restart my_daemon.service

опять запускаем параллельно лог и процесс и наблюдаем как процесс перезапустился

красота! =)

Перехватываем HUP сигнал

Команда reload

В systemd помимо уже знакомых нам команд start, restart, stop встроена еще одна полезная команда, которая называется reload.

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

Правда если попробовать запустить эту команду, то увидим что-то такое

ну то есть наш сервис не поддерживает reload

Чтобы он стал его поддерживать надо добавить пункт ExecReload в описание сервиса

[Unit]
Description=Заклинатель книг

[Service]
User=m
Restart=on-failure
WorkingDirectory=/home/m/projects/daemon/bin/Debug/net7.0
ExecStart=/home/m/projects/daemon/bin/Debug/net7.0/daemon -f config.txt
ExecReload=/bin/kill -HUP $MAINPID # вот тут

[Install]
WantedBy=multi-user.target

теперь если попробовать выполнить reload сервиса мы увидим, что процесс останавливается.

Дело в том, что по умолчанию HUP сигнал обрабатывается как сигнал остановки. Причем он считается корректным сигналом остановки и супервизор не пытается перезапустить процесс.

В общем, чтобы поменять такое поведение надо подключить собственный обработчик к этому сигналу.

В .net 6 как раз добавили поддержку linux сигналов и можно легко сделать собственный обработчик, если запихать в Main что-то такое

using System;
using System.IO;
// ...
using System.Runtime.InteropServices;  // не забывем добавить using

namespace daemon
{
    class Program
    {
        static int Main(string[] args)
        {
            // подключаем обработчик
            PosixSignalRegistration.Create(PosixSignal.SIGHUP, (context) => {
                context.Cancel = true; // отключаем обработчик по умолчанию
                Console.WriteLine("обновляюсь без перезагрузки"); 
            });
            // ...
        }
        
        // ...
    }
}

билдимся и запускаем процесс по новой

sudo systemctl start my_daemon.service

вот теперь другое дело. Можно и задание пилить =)

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

К счастью существует более эффективный способ общения с юзером. С помощью так называемых сокетов.

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

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

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

Есть разные протоколы взаимодействия с сервером. Мы будем использовать протокол TCP/IP, потому что данный протокол предполагает создание диалога между пользователем (клиентом) и демоном (сервером), что идеально подходит под нашу ситуацию. Можно теперь забыть про наш старый код с FileSystemWatcher-ом и циклом с Thread.Sleep. Теперь у нас будет нормальный сервер который сам будет ждать соединения, в общем, пишем:

using System;
using System.Net.Sockets;
using System.Text;

namespace App
{
    class Program {
        public  static void Main(String[] args) {
            // проверяем не создали ли мы сокет файл уже
            // и если создали то удаляем старый файл
            if (File.Exists("daemon.socket")) {
                File.Delete("daemon.socket");
            }
            
            // собственно создаем канал для сокета
            UnixDomainSocketEndPoint endPoint = new("daemon.socket");
            // создаем объекта сокета
            var socket = new Socket(
                endPoint.AddressFamily,
                SocketType.Stream,
                ProtocolType.IP
            );
            
            // подключаем к каналу
            socket.Bind(endPoint);
            // и начинаем слушать соединения
            socket.Listen();

            while(true) {
                Console.WriteLine("Жду приказов");
                
                var handler = socket.Accept(); // эта строка блокирует код пока кто-нибудь не подключится к сокету
                
                // как только кто-то подключился мы можем начать обрабатывать команды от юзера
                while (true) {  
                    var bytes = new Byte[1024];   // буфер под введенные данные
                    int bytesRec = handler.Receive(bytes);   // эта штука по сути аналог Console.ReadLine()
                    var input = Encoding.UTF8.GetString(bytes); // только полученные байты превращаем в строку
                    var output = $"Вы написали {input}"; // формируем ответ
                    handler.Send(Encoding.UTF8.GetBytes(output)); // посылаем ответ, преобразуя его обратно в байты
                }  
            }
        }
    }
}

попробуем запустить

dotnet run

если глянуть, то увидим, что в папке появился файлик daemon.socket

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

Можно попробовать туда чего-нибудь echoнуть

правда оно не сработает так как это не настоящий файл.

В общем чтобы к нему подключится нам потребуется специальная программа для подключения к сокетам. Называется она socat. Ставим ее себе

sudo apt install socat

Теперь попробуем подключится к серверу. Пишем

socat UNIX-CLIENT:daemon.socket -

и попробуем чего-нибудь пописать

чтобы остановить общение надо нажать Ctrl+C

это разорвет соединения socat, и заодно убьет наш сервер так для него такая ситуация является нештатной, что конечно такое себе.

В общем надо ловить эту ошибку и в случае ее возникновения прерывать соединения корректно вот так

// ...
while(true) {
    // тут не трогаем
    Console.WriteLine("Жду приказов");

    var handler = socket.Accept(); 
    
    // а цикл правим
    while (true) {  
        try { // обернул в try
            // тут старый код который раньше был в while
            var bytes = new Byte[1024]; 
            int bytesRec = handler.Receive(bytes);
            var input = Encoding.UTF8.GetString(bytes);
            var output = $"Вы написали {input}";
            handler.Send(Encoding.UTF8.GetBytes(output));
        } catch (SocketException) { // ловлю ошибку
            // в случае ошибки пишу об этом
            Console.WriteLine("Произошёл разрыв соединения");  
            // закрываю соединения аккуратно
            handler.Shutdown(SocketShutdown.Both); 
            handler.Close();  
            break; // и выхожу из цикла перехвата ввода
        }
    }  
}
// ...

Пробуем запустить

Отлично!

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

Делается это так

using System;
using System.Net;  // не забыть добавть using
using System.Net.Sockets;
using System.Text;

namespace App
{
    class Program {
        public  static void Main(String[] args) {
            // узнаем системный IP
            IPHostEntry ipHostInfo = Dns.GetHostEntry(Dns.GetHostName());  
            IPAddress ipAddress = ipHostInfo.AddressList[0];  
            // создаем точку подключения
            IPEndPoint endPoint = new IPEndPoint(ipAddress, 8080);  
            Console.WriteLine($"Слушаю запросы на {ipAddress}:8080");
            
            // ну и дальше как обычно
            var socket = new Socket(
                endPoint.AddressFamily,
                SocketType.Stream,
                ProtocolType.IP
            );
            
            socket.Bind(endPoint);
            socket.Listen();
            
            //...
        }
    }
}

И теперь если захочется подключится к серверу просто пишем вот так:

socat TCP:127.0.1.1:8080 -

вот теперь другое дело, можно пилить задачу

Попробуем теперь еще улучшить наш сервер, сейчас он может обрабатывать только одно соединение. Если к сокету попробует подключится кто-то еще, то он встанет в очередь и будет ждать пока прекратит общение предыдущий собеседник.

На самом деле такой подход применяется и в жизни. Просто клиент не держит соединение вечно, а делает запрос, дожидается ответа и разрывает коннект. Чтобы обеспечить параллельность разворачивают несколько копий приложения, поверх которых работает прокси сервер, который равномерно распределяет запросы к серверу по всем запущеным копиям.

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

Для этого воспользуемся возможностью писать асинхронные штуки в C#

Я пока не успел тут дописать методичку, так что пока можете потыкать сами =)

https://docs.microsoft.com/ru-ru/dotnet/framework/network-programming/asynchronous-server-socket-example