Будут задействованы две вещи:
Прежде чем начать, обратите внимание, что вы можете предпочесть выполнить шаг 2, прежде чем стирать RHEL.
Cron может зависнуть, если одно из его заданий зависает (, например, если у вас неправильно настроена ротация журнала и т. д. ).
Чтобы найти виновника, запустите pstree перед перезагрузкой, чтобы увидеть, активны ли какие-либо процессы или зависли:
pstree -ap $(pidof cron)
Вы также можете посмотреть, какие задания cron определены в
/etc/crontab
/etc/cron.d/
/etc/cron.daily/
/etc/cron.hourly/
/etc/cron.monthly/
/etc/cron.weekly/
, а такжеcrontab -l
(для каждого пользователя ).
Если это не поможет вам решить вашу проблему, вы можете использовать это как обходной путь:
редактировать/etc/systemd/system.conf
установить DefaultTimeoutStopSec в разделе «Менеджер»
[Manager]
DefaultTimeoutStopSec=5s
бежатьsystemctl daemon-reload
Это укажет systemd ждать только 5 секунд, пока процесс crond завершится.
Та же проблема на моем Xubuntu 20.04 уже 2 недели.
Для выяснения источника этого сообщения, отображаемого при завершении работы
Reached target Reboot.
systemd-shutdown[1]: Waiting for process: crond
Я использовал эту команду для получения списка файлов заданий cron (, упорядоченных по дате):
find /etc/cron* -type f | xargs ls -ltr
Я обнаружил, что файл /etc/cron.d/collect(только что обновленный )планировал странный двоичный файл с именем /var/tmp/crond
Я решил отключить это задание, переместив /etc/cron.d/collect в другое место (в моем домашнем каталоге, чтобы попытаться удалить его навсегда ).
После 2-х перезагрузок я проверил, что я восстановил быстрое завершение работы!
(также можете пройти по этой ссылке:https://askubuntu.com/a/1329933)
Я могу подтвердить ответ Жиля Гайдо. В моем случае эти файлы
вероятно, были созданы "Free Download Manager" версии 6.X
Удаление этого программного обеспечения не привело к удалению этих файлов, поэтому я сделал то, что описывает Жиль Гайдо, но дополнительно удалил /var/tmp/bs