Systemd freezing execution что это
Systemd за пять минут
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
Команды на старт/стоп и релоад сервиса
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
Systemd, интерактивные скрипты и таймеры
Введение
При разработке под linux возникают задачи создания интерактивных скриптов, выполняемых при включении или завершении работы системы. В system V это делалось легко, но с systemd вносит коррективы. Зато оно умеет свои таймеры.
Зачем нужны target
Пример target при включении(обзор возможности) с запуском интерактивного скрипта
Описание самого target:
Данный target запустится, когда будет запущен multi-user.target и вызовет installer.service. При этом таких сервисов может быть несколько.
И наконец, пример выполняемого скрипта:
Самое главное — выбрать final.target — target, к которому система должна придти при запуске. В процессе запуска systemd пройдёт по зависимостям и запустит всё нужное.
Выбрать final.target можно разными способами, я использовал для этого опцию загрузчика.
Итоговый запуск выглядит так:
Подготовка прошивки к запуску
При создании прошивок всегда возникает задача восстановления состояния системы при старте и его сохранении при выключении. Под состоянием подразумеваются конфигурационные файлы, дампы базы данных, настройки интерфейсов и тд.
Systemd запускает процессу в одном таргете параллельно. Есть зависимости, которые позволяют определить последовательность запуска скриптов.
Важны файлы сервисов, именно они выставляют последовательность их запуска
Как видно, я поставил зависимости, что бы сначала отработал мой скрипт, а только потом поднималась сеть и стартовала СУБД.
И второй сервис(подготовка zabbix)
Здесь немного сложнее.Запуск так же в multi-user.target, но ПОСЛЕ запуска СУБД postgresql и моего setting_restore. Но ПЕРЕД запуском служб zabbix.
Сервис с таймером для logrotate
Systemd может заменить CRON. Серьезно. Причем точность не до минуты, а до секунды(а вдруг понадобится).А можно создать монотонный таймер, вызываемый по таймауту от события.
Именно монотонный таймер, считающий время от запуска машины, я и создал.
Для этого потребуется 2 файла
logrotateTimer.service — собственно описание сервиса:
Всё просто — описание команда запуска.
Второй файл logrotateTimer.timer — вот он и задает работу таймеров:
Интерактивный скрипт при выключении и свой таргет выключения
В другой разработке мне пришлось делать более сложный вариант выключения машины — через собственный таргет, что бы выполнить множество действий. Обычно рекомендуется создать сервис oneshot с опцией RemainAfterExit, но это не дает создать интерактивный скрипт.
А дело в том, что команды, запускаемые опцией ExecOnStop выполняются вне TTY! Проверить просто — вставьте команду tty и сохраните её вывод.
Поэтому я реализовал выключение через свой таргет. На 100% правильность не претендую, но это работает!
Как это делалось(в общих чертах):
Создал таргет my_shutdown.target, который ни от кого не зависел:
my_shutdown.target
При переходе в этот таргет(через systemctl isolate my_shutdwn.target), он запускал сервис my_shutdown.service, задача которого простая — выполнить скрипт my_shutdown.sh:
Примечание. Использование файлов /tmp/reboot и /tmp/shutdown. Нельзя вызвать target с параметрами. Можно только service.
Но я использую target, что бы иметь гибкость в работе и гарантированный порядок выполнения действий.
Однако, самое интересное было потом. Машину же надо выключить/перезагрузить. И тут есть 2 варианта:
Я выбрал первый вариант. В systemd reboot(как и poweroff) являются симлинками на systemd.
Поэтому их можно заменить на свои скрипты:
reboot
Трагедия systemd
Согласно Википедии, трагедия — это «форма драмы, основанная на человеческих страданиях, которая вызывает в аудитории сопутствующий катарсис или удовольствие». Из этого определения почерпнул вдохновение Бенно Райс в своём выступлении на конференции 2019 linux.conf.au. Его доклад посвящён истории systemd, в которой немало страданий. А аудитория точно получила удовольствие, так что всё сходится. В целом, это сочувственный и тонкий взгляд на одну бурную главу в истории системы Linux.
Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.
Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.
Истоки трагедии
По словам Райса, происхождение systemd связано с корнями самой системы Unix, которая была «счастливой случайностью» — реакцией на внешнюю сложность прежних систем. Unix был кардинально упрощён во всех отношениях, включая загрузку пользовательского пространства. Подсистема init заведовала всем «хозяйством», включая монтирование файловых систем и запуск демонов. Хотя это совершенно разные задачи, но их объединили в один процесс.
А потом случился Интернет. Хотя inetd нормально справлялся с небольшими объёмами трафика, но не мог создавать новый процесс на каждое входящее соединение. Тем временем веб-сайты обзавелись базами данных и другими системами с сохранением состояния между соединениями. Представление о демоне сместилось в сторону «сервиса», а это совсем другой зверь. Старый init мог только запустить сервис, но после этого становился практически бесполезен.
Сервисный уровень
Классические Unix-подобные системы делятся на два основных компонента: ядро и пользовательское пространство. Но ядра со временем стали более динамичными и изменчивыми, подстраиваясь под оборудование, на котором они работают. Это привело к необходимости создания нового «сервисного слоя» (service layer) между ядром и пользовательским пространством. Этот слой включает в себя компоненты вроде udev и Network Manager, но systemd стремится обеспечить комплексный сервисный уровень; именно поэтому со временем он вбирал в себя функциональность таких компонентов как udev. Процесс шёл довольно успешно и был принят большинством (но не всеми) дистрибутивами Linux, хотя часто сопровождался язвительностью со стороны сообщества.
Против демона systemd часто звучат одни и те же аргументы: например, что он нарушает философию Unix. Райс предполагает, что этот аргумент основан на понятии, что systemd представляет собой единый монолитный двоичный файл. На самом деле systemd структурирован иначе: это много отдельных двоичных файлов, поддерживаемых в рамках одного проекта. Как «человек BSD» (он входил в число основных разработчиков FreeBSD), Райс находит смысл в таком объединении смежных концепций. Systemd — вовсе не раздутая и монолитная система, как считают некоторые критики.
Говорят, что в systemd много багов. «Это же софт», конечно, в нём будут баги, сказал Райс. Представление о том, что в отличие от любой другой системы systemd должен быть совершенным, поднимает планку слишком высоко. По крайней мере, у systemd практически всегда разумный режим работы при отказе, сказал он.
В той или иной форме часто повторяется одна жалоба, которую можно сформулировать так: «Не выношу Леннарта Пёттеринга». Райс отказался защищать стиль общения Пёттеринга, но сказал, что нельзя не восхититься силой воли и решимостью Пёттеринга. Не каждый сможет пройти через всё это.
Systemd не стремится к портируемости на системы, отличные от Linux, что приводит к отдельному классу жалоб. Если systemd станет стандартом, существует риск того, что операционные системы за пределами Linux станут ещё более изолированными. Многие хотят, чтобы systemd придерживался стандартных для Unix интерфейсов, но у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления» (что человеку от FreeBSD больно говорить), и нет смысла придерживаться классических интерфейсов Unix. Нынешняя ситуация является «патологической монокультурой», где Linux может диктовать условия.
Systemd много выиграл в такой ситуации. Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD. Разработчики систем типа FreeBSD могут видеть угрозу в непереносимости systemd. Но эта ситуация также даёт им возможность свободно работать и искать собственные решения этих проблем.
Перемены и трагедия
Райс говорит, что миссия systemd сводится к большим разрушительным изменениям — вот где начинается трагедия. У нас нердов сложное отношение к изменениям. Да, это потрясающе, когда мы сами их создаём, но изменениям нельзя доверять, если они приходят извне. Systemd представляет тот вид внешне навязанных изменений, который люди находят угрожающим. Люди противятся таким изменениям даже от приятных разработчиков, не говоря уже о Пёттеринге, который не особо сочувствует окружающим. Это приводит к рефлекторным реакциям. Но людям нужно отступить и подумать, что они делают. «Никто не должен угрожать Леннарту смертью из-за какого-то программного обеспечения», — говорит Райс. Презрение — это не круто.
Вместо этого стоит подумать: почему вообще появился systemd и почему это важно? Какую проблему он решает? Для критиков одним из решением может быть попытка создать собственную альтернативу: они поймут, насколько весёлая эта задача. Кроме всего прочего, эта история показывает разницу в мышлении у нового поколения, которое рассуждает о системах больше с точки зрения API и контейнеров, например.
Итак, какие выводы можно сделать из истории systemd? Один из выводов: нельзя недооценивать транспорт сообщений. Systemd интенсивно использует шину D-Bus, которая во многом обеспечивает его гибкость. Райс не сторонник D-Bus, но большой сторонник шин для обмена сообщениями между процессами. В своё время он лоббировал создание такой нативной шины в BSD-системах, желательно встроенной в ядро и с лучшей безопасностью, чем у D-Bus. Поверх неё можно сделать надлежащую систему удалённого вызова процедур, где компоненты ядра и пользовательское пространство будут работать на одном уровне. В правильно спроектированной системе процесс просто отправит запрос API, не беспокоясь о том, где и как этот запрос будет обработан.
Среди прочих уроков — важность поддержки надлежащего жизненного цикла службы без необходимости установки дополнительных систем управления службами. Важно наладить автоматизацию обслуживания через API; и systemd обеспечивает многое из этого. Поддержка контейнеров также важна: это полезный способ инкапсуляции приложений.
Итак, в современных Linux-системах systemd выполняет роль сервисного слоя. Это хорошая платформа для управления службами, но она не должна быть единственной альтернативой. В systemd есть ряд полезных функций, включая удобные пользовательские юниты, последовательное именование устройств и даже хорошую модель журналирования, сказал Райс. Двоичные журналы — неплохая вещь, пока у вас есть инструменты, чтобы вытащить оттуда информацию. И systemd предоставляет новую модель приложения. Вместо одного двоичного файла приложение становится кучей модулей в одном контейнере.
Мир вокруг нас меняется, сказал Райс. Мы можем либо отдаться течению, либо сопротивляться ему. В первом случае, вероятно, плыть будет проще, чем во втором. Райс предложил всем, кто критикует systemd, более пристально изучить эту систему и попытался найти в ней хорошие вещи. Возможно, тогда завершится фаза катарсиса нашей трагедии — и мы сможем двигаться дальше.
Пять инструментов systemd, которые стоит начать использовать прямо сейчас
Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.
Когда наконец удается смириться с уходом systemd от тех принципов, что лежали в основе ветхозаветной System V с ее простыми текстовыми файлами и засильем скриптов, начинаешь видеть неоспоримые преимущества новой системы инициализации и поставляемых с ней инструментов. В этой статье мы поговорим о четырех из них, а также упомянем еще один, который вы наверняка уже знаете, но вряд ли использовали описанным здесь способом.
coredumpctl
Этот инструмент, как услужливо подсказывает его имя, используется для получения дампов памяти из журнала systemd.
Команда coredumpctl вернет общий список всех дампов памяти, в котором могут быть записи за несколько недель, а то и месяцев работы системы.
Рис. 1. coredumpctl выводит список всех дампов памяти, зарегистрированных в журнале
Эта команда выведет все детали последнего дампа с PID 1758. А поскольку журнал systemd охватывает более одной сессии (мой, например, начинается с мая), в нем могут оказаться несколько не связанных друг с другом дампов от процессов с одинаковым PID.
Рис. 2. Модификатор dump позволяет получить более подробную информацию о дампе памяти
Также есть возможность установить фильтр по имени исполняемого файла:
Как и в случае с PID, эта команда выведет информацию только о последнем дампе, поскольку в большинстве случаев нужен именно он.
В фильтре дампа памяти может использоваться PID, имя исполняемого файла, путь, который должен содержать как минимум одну косую черту (например, /usr/bin/name_of_executable), а также один или несколько общих предикатов (general predicates) journalctl. Последний вариант показан в следующем примере:
Помимо dump у сoredumpctl есть и другие опции. Для тех, кто хочет сразу начать отладку, следующая команда не только выведет всю информацию о дампе, но и откроет GNU debugger (gdb):
bootctl
А вы знаете, что загрузкой теперь управляет systemd-boot, а не GRUB? Да, это очередная функция, которую подмял под себя, кажется, уже не способный остановиться systemd. Правда, это пока касается только систем с UEFI.
Обучение настройке загрузчика выходит за рамки данной статьи (если вам действительно интересно, найти полезную информацию можно здесь), однако для установки пользовательской конфигурации загрузки необходимы хотя бы базовые знания bootctl.
(Если вы новичок в Linux, не пугайтесь. Вам, скорее всего, не придется делать ничего из представленного в данном разделе. Об этом позаботится ваш дистрибутив. Все, что здесь написано, в первую очередь предназначено для энтузиастов абсолютного контроля (например, пользователей Arch Linux). Эти люди не могут спать спокойно, пока в их системе остался хотя бы один параметр, который они не пробовали подкрутить.)
Для работы с bootctl нужны права суперпользователя, поэтому обращаться с этим инструментом нужно уважительно. Одно неосторожное движение — и ваша система перестанет загружаться.
Один из самых безобидных режимов bootctl — проверка статуса загрузки. Если /boot не указывает на раздел FAT EFI напрямую, нужно вручную с помощью опции —path= указать путь к загрузочному разделу EFI. Вот как выглядит команда для моей openSUSE:
Рис. 3. Инструмент bootctl позволяет просматривать и изменять настройки программы управления загрузкой
В выводе команды можно найти опции загрузки и расположение бинарного файла загрузчика (ESP).
Измененная конфигурация загрузки устанавливается с помощью команды:
Эта команда также сгенерирует бинарный файл systemd-boot, сохранит его в boot/path/to/efi/EFI/Boot и добавит соответствующий вызов в верхнюю часть списка приоритета загрузки.
Чтобы обновить systemd-boot, выполните:
Для удаления systemd-boot из раздела EFI используйте:
Будьте осторожны с последней командой.
systemd-cgtop, systemctl и systemd-cgls
Если классический top позволяет найти процессы, больше других нагружающие CPU и активнее потребляющие память, systemd-cgtop делает то же самое для контрольных групп (cgroups).
Cgroups представляет из себя механизм разбиения и изолирования ресурсов системы для предоставления их группам пользователей и задач. Например, вы можете применить cgroups для установки ограничений на потребление памяти и CPU в системе, где работают две группы пользователей. Полное описание cgroups с примерами можно найти здесь.
systemd использует cgroups для контроля своих служб, а systemd-cgtop позволяет убедиться, что все группы ведут себя прилично. Если кто-то все-таки начал безобразничать, можно одним махом завершить работу сразу всей группы, а не разыскивать и останавливать каждый процесс в отдельности.
Взгляните на рисунок 4, где изображен пример нормально работающей системы. Никто не злоупотребляет ресурсами, и числового обозначения в строке с итогами удостоились только общие показатели активности всех групп системы. При этом я мог бы избавиться, например, от auditd, веди он себя неподобающим образом. И поскольку система без этого сервиса не остановится, так и сделаю:
И… та-дам! Его больше нет!
Рис. 4 systemd-cgtop сообщает о поведении cgroups
В данном случае у auditd.service были две связанные с ним задачи, но их могут быть сотни, особенно у групп, используемых для конечных пользователей, поэтому systemctl очень удобен для работы с cgroups.
Кстати, чтобы посмотреть, какие процессы связаны с той или иной cgroup, попробуйте команду systemd-cgls /cgroup.name
И вы увидите все процессы, работающие в подгруппе NetworkManager.
Заключение
Мы рассмотрели лишь малую часть предназначенных для системного администрирования инструментов systemd. Их, конечно, намного больше, и в следующей статье мы поговорим еще о нескольких. Также стоит помнить, что настоящая сила многих инструментов скрыта в их многочисленных опциях.
Если вы хотите получше разобраться в вопросах, связанных с systemd, рекомендую начать с идущей в комплекте документации:
Systemd для самых маленьких. Часть I. Знакомство
Внимание! Данный пост не для холивара в стиле «нужен/не нужен», «не unix-way», «когда Поттеринг запилит свою ось?» и т.п. Пост содержит исключительно информацию по работе с systemd.
Привет вам, красноглазые братья и сёстры!
Эта статья посвящена, как видно из названия, системе systemd. Первый пост скорее обзорный и начнем мы с вами с исторического экскурса.
Глава 1. В плену shell-скриптов.
Уровень по умолчанию задавался в файле /etc/inittab, а поменять на лету можно было при помощи команды init номер_уровня. Например,
для выключения машины. Все скрипты запускались последовательно (это важно!). Позднее Ubuntu запилила свою СИ с блэкджеком и событийной моделью под именем upstart. Но о ней мы говорить не будем, т.к. даже сама Ubuntu отказалась от неё в пользу systemd.
Ладно, переборщил я со вступлением. Держите скрин и переходим к «виновнику торжества».
Глава 2. Systemd и все-все-все.
systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает мгновенные снимки и восстановление состояния системы, монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций.
На сегодняшний день sd применяется в Debian (c 8-й версии), Ubuntu (с 15.04 версии), Fedora (c 15 версии), openSUSE (с 12.1), ArchLinux (12.11) и т.д.
Расположены директории в порядке повышения приоритета.
Юниты можно запускать и останавливать.
Как я сказал, юниты делятся на типы (с соответ. расширениями файлов):
Конечно, можно просто открыть файл в текстовом редакторе или использовать утилиту cat, но гораздо удобнее использовать для этого спец. команду;
Секция [Unit] содержит основную информацию о юните, а также о зависимостях порядка и зависимостях требования. Итак, параметры:
Зависимости порядка и зависимости требования НЕ связаны между собой. В данном примере, сказано, что sshd.service должен запустится после network.target. Но это никоим образом не значит, что network.target будет запущен! Однако если он запущен (допустим, его запустил другой сервис), то стартуем после него, если не запущен, то и фиг с ним.
Но вернемся к sshd. Секция [Service] описывает тип юнита service. В других типах своё. Например, в юнитах типа socket есть секция [Socket]
Секцию [Install] пока просто запомним, ниже расскажу, где она используется.
Пока вы должны понять, что есть такая сущность, как юнит, что юниты делятся на типы и что юниты объединяются в дерево зависимостей на основе зависимостей требования и зависимостей порядка.
Глава 3. Одна за всех.
Прежде чем начинать описывать команды, хотелось бы пару слов сказать про юнит типа target. Как кратко было сказано выше, этот тип юнита не делает ничего, просто объединяя другие юниты. Технически этот юнит представляет из себя директорию с симлинкми на другие юниты.
Target-ы являются аналогами уровней в SysVinit. Т.е., допустим, target с именем multi-user является аналогом 2/3 уровня и содержит симлинки на юниты, которые будут запущены при выполнении этого target-а. По умолчанию выполняется target с именем default.target, который обычно является псевдонимом для graphical.target (аналог 5 уровня).
Итак команды. Основная команда, это
systemctl, запущенная без параметров, является псевдонимом для более полной команды systemctl list-units. Она покажет список юнитов, а также их состояния. С помощью ключа -t можно задать тип юнитов, а —all выведет все юниты, в том числе и неактивные. Например:
покажет общее состояние системы и перечислит юниты, которым соответствуют какие-либо запущенные процессы. В то же самое время, эта команда, дополненное именем юнита покажет более подробную информацию о юните. Например:
покажет содержимое юнита.
systemctl stop unit_name
Примечание: по умолчанию принимается тип service. Таки образом команды
systemctl start sshd.service
systemctl start sshd
Тут все просто и понятно. Единственное, что стоит уточнить, так это то, что эти манипуляции применяются только в текущей сессии. При рестарте все вернется на круги своя.
А что тогда делать, если мы хотим добавить юнит в автозагрузку? Опять systemctl
systemctl disable unit_name
Еще помните секцию Install, которую я сказал, что опишу позднее? Если не помните, то вот она:
Ну так вот, эта секция используется командами systemctl enable/disable для добавления симлинка в нужный target (создания иск. зависимости). Конкретно в этом случае, при выполнении команды
в папке multi-user.target будет создан симлинк на sshd.service и при выполнении данного target-a sshd будет запущен.
Кстати, проверить наличие юнита в автозагрузке можно командой
Она вернет enabled/disabled. Логично же)
просто удаляет симлинк.
Само собой, что можно просто запустить нужный target. Например:
Но гораздо проще использовать сокращенный аналог, убрав start и target, т.е.:
Также у нас имеется «лицензия на убийство»
Хотите перезапустить все юниты и перестроить дерево зависимостей? Не проблема
