Имеет ли systemd другой тайм-аут при перезагрузке или обычном перезапуске службы?

Использует ли systemd другой тайм-аут для остановки работающего демона (например, rsyslog ) при перезагрузке системы (например, путем reboot ) и при простом перезапуске демона (например, systemctl restart rsyslog )?

Я проверил страницу systemd.service , но я этого не заметил . Вместо этого я нашел параметры TimeoutStopSec и TimeoutStartSec . Я установил параметр TimeoutStopSec , но кажется, что systemd может убить демона, прежде чем он сможет безопасно сохранить свое состояние и закончить чисто .

ИЗМЕНИТЬ 1:

Как предложил @sourcejedi (спасибо), я должен подчеркнуть, что это не установка на рабочем столе, где работает rsyslog, а серверная установка Ubuntu 16.04 для rsyslog, которая получает сообщения от клиентских узлов и все еще может содержать много сообщений в памяти, когда их просят прекратить по systemd.

Я попытался помочь решить проблемы с поврежденной дисковой очередью, увеличив значение параметра TimeoutStopSec с 90 секунд до 240 секунд, но я все еще наблюдал это сообщение несколько раз в соответствующем файле журнала:

 rsyslogd: queue 'strm 0x26b4800', файл '/var/spool/rsyslog/q_ForwardToNode2.00000003' открыт для записи без добавления, но уже содержит 983505 байт. [v8.29.0 try http://www.rsyslog.com/e/ 0]

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

Я попытался обойти еще одну проблему, заставив systemd ждать активного сетевого подключения, прежде чем пытаться запустить rsyslog. Я включил содержимое обоих системных Drop-Ins которые я использую ниже для справки, если он добавит полезный контекст к этой записи.

cat /etc/systemd/system/rsyslog.service.d/*.conf | grep -Ev '#|^$'

Попытка работать с github # 1656

 [Ед. изм]
 Документация = https: // внутренний / вики / URL / здесь
 После того, как = network.target
 Хочет = nework.target

Попытка обойти github # 1704

 [Ед. изм]
 Документация = https: // внутренний / вики / URL / здесь
 [Обслуживание]
 TimeoutStopSec = 240

Спасибо за чтение этого.

  • systemd "onehot" для запуска poweroff
  • Может ли система сохранить состояние при перезагрузке?
  • Какова практическая разница между `systemctl start reboot.target` и` systemctl reboot`?
  • Предельная перезагрузка системы
  • Перезагрузите все службы без перезагрузки
  • One Solution collect form web for “Имеет ли systemd другой тайм-аут при перезагрузке или обычном перезапуске службы?”

    При выдаче команды перезагрузки systemd игнорирует значение TimeoutStopSec?

    Нет. Это было бы ужасно, и это не то, что происходит.

    EDIT: В некоторых версиях systemd выше v233 добавляется JobTimeoutSec=30min reboot.target на reboot.target . Таким образом, в этом случае будет верхний предел (после чего блок запустит перезагрузку), но он в несколько раз превышает значения, которые вы уже установили.

    EDIT: Re "идея заключалась в том, что система может быть нетерпеливой и убивает rsyslog, пока он все еще сохраняет содержимое на диск", сообщение, похоже, было ошибкой в ​​rsyslog.

    ошибка очереди: сообщение об ошибке записи файла было неправильным # 1759 # 1759

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


    Посмотрев на служебные файлы на Debian 9, обратите внимание, что syslog.socket (поставляемый systemd) имеет DefaultDependencies=no , но также Before=shutdown.target и Conflicts=shutdown.target . Прокомментирована последняя строка. Don't allow logging until the very end . Если у вас не было этих двух последних, и у rsyslog.service был DefaultDependencies=no , демон syslog можно было бы повторно активировать немедленно, а вместо этого быть убитым с помощью systemd-shutdown.service ( systemd-shutdown ). systemd-shutdown использует встроенный тайм-аут по умолчанию между SIGTERM и SIGKILL, который, я думаю, составляет 90 секунд.

    Interesting Posts
    Linux и Unix - лучшая ОС в мире.