systemd работает внутри с точки зрения очереди «заданий». Каждое задание (немного упрощенное) - это действие, которое необходимо выполнить: остановить, проверить, запустить или перезапустить определенный модуль .
Когда (например) вы указываете systemd запустить сервисный модуль , он разрабатывает список заданий остановки и запуска для любых модулей (сервисных модулей, монтажных блоков, блоков устройств и т. Д.), Необходимых для достижения этой цели, в соответствии с требования и зависимости юнитов, упорядочивает их, в соответствии с отношениями упорядочения юнитов, разрабатывает и (если возможно) устраняет любые внутренние противоречия и (если этот последний шаг успешен) помещает их в очередь.
Затем он пытается выполнить поставленные в очередь «задания».
Задание остановки выполняется для сеанса 1 пользователя xy
Блок отображаемое имя здесь Session 1 of user xy. Это будет (из отображаемого имени) единица сеанса , а не единица обслуживания . Это абстракция сеанса входа в пользовательское пространство, которая поддерживается программой systemd logindи ее плагинами PAM. Это (по сути и в теории) группировка всех процессов, которые этот пользователь выполняет как «сеанс входа в систему».
Работа, которая была поставлена в очередь на это stop. И это, вероятно, занимает много времени, потому что системные пользователи ошибочно связывают зависание сеанса с отключением сеанса . Они ломают первое, чтобы заставить второе работать, и в ответ некоторые люди изменяют systemd, чтобы сломать второе, чтобы заставить первое работать. Системные люди действительно должны признать, что это две разные вещи.
В сеансе входа в систему у вас есть что-то, что игнорируется SIGTERMили требует много времени для завершения, как только оно увидит SIGTERM. По иронии судьбы, первое - это давнее поведение некоторых оболочек контроля работы. Правильный способ прервать лидеров сеансов входа в систему, когда они являются этими конкретными оболочками управления заданиями, - это сказать им, что сеанс завис , после чего они прекращают все свои задания (другой тип задания для внутреннего задания systemd), а затем прекратить себя.
На самом деле происходит то, что systemd ожидает время ожидания остановки устройства, пока оно не прибегнет к SIGKILL. Разумеется, этот тайм-аут настраивается на единицу и может быть установлен так, чтобы он никогда не превышался. Следовательно, почему можно увидеть различное поведение.
дальнейшее чтение