Что за дистрибутив установлен? Какая версия systemd установлена? Воспроизводится ли проблема, если обновить systemd?

Feel free to reopen this bugreport.

Для e2k на тот момент был один дистрибутив, обновлений для платформы e2k вообще не было.

Как можно быть уверенным, что это systemd?

Переоткрою.

Т.е., это поведение в Альте на e2k?

mike@, перевешу тогда на тебя пока (bircoph@ в копии).

(В ответ на комментарий №4)
> Т.е., это поведение в Альте на e2k?
 
Да, я там архитектуру указывал, не надо было её сносить :-)

У пользователя Δημητριος такая же ситуация на SimplyLinux 9.0 x86_64.
Вот ссылка на форум, где он это описывает и приложил часть лога:
https://forum.altlinux.org/index.php?topic=44397.0
[code]journalctl -b 0
Νοε 21 13:03:25 user-PC apcupsd[3020]: apcupsd FATAL ERROR in smartsetup.c at line 155
                                          PANIC! Cannot communicate with UPS via serial port.
                                          Please make sure the port specified on the DEVICE directive is correct,
                                          and that your cable specification on the UPSCABLE directive is correct.
Νοε 21 13:03:25 user-PC apcupsd[3020]: apcupsd error shutdown completed
Νοε 21 13:03:32 user-PC systemd[1]: systemd-hostnamed.service: Succeeded.
Νοε 21 13:03:38 user-PC nmbd[3041]: [2020/11/21 13:03:38.488337,  0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
Νοε 21 13:03:38 user-PC nmbd[3041]:   *****
Νοε 21 13:03:38 user-PC nmbd[3041]: 
Νοε 21 13:03:38 user-PC nmbd[3041]:   Samba name server USER-PC is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.154
Νοε 21 13:03:38 user-PC nmbd[3041]: 
Νοε 21 13:03:38 user-PC nmbd[3041]:   *****
Νοε 21 13:03:41 user-PC lightdm[2807]: pam_tcb(lightdm:auth): Authentication passed for user from (uid=0)
Νοε 21 13:03:41 user-PC systemd[1]: session-1.scope: Killing process 2771 (lightdm) with signal SIGTERM.
Νοε 21 13:03:41 user-PC systemd[1]: session-1.scope: Killing process 2782 (lightdm-gtk-gre) with signal SIGTERM.
Νοε 21 13:03:41 user-PC systemd[1]: session-1.scope: Killing process 2800 (at-spi-bus-laun) with signal SIGTERM.
Νοε 21 13:03:41 user-PC systemd[1]: session-1.scope: Killing process 2805 (dbus-daemon) with signal SIGTERM.
Νοε 21 13:03:41 user-PC systemd[1]: Stopping Session 1 of user _ldm.
Νοε 21 13:03:41 user-PC systemd[1]: session-1.scope: Succeeded.
Νοε 21 13:03:41 user-PC systemd[1]: Stopped Session 1 of user _ldm.
Νοε 21 13:03:41 user-PC lightdm[2807]: pam_tcb(lightdm:session): Session opened for user by (uid=0)
Νοε 21 13:03:41 user-PC systemd-logind[2625]: Removed session 1.
Νοε 21 13:03:41 user-PC systemd[1]: Created slice User Slice of UID 500.
Νοε 21 13:03:41 user-PC systemd[1]: Starting User Runtime Directory /run/user/500...
Νοε 21 13:03:41 user-PC systemd-logind[2625]: New session 3 of user user.
Νοε 21 13:03:41 user-PC systemd[1]: Started User Runtime Directory /run/user/500.
Νοε 21 13:03:41 user-PC systemd[1]: Starting User Manager for UID 500...
Νοε 21 13:03:41 user-PC systemd[3058]: pam_tcb(systemd-user:session): Session opened for user by (uid=0)
[/code]
[/quote]

(Ответ для Aceler на комментарий #0)
> Иногда не происходит перезагрузка/выключение по команде reboot или по
> нажатию на пункт меню в DE. Доходит до конца systemd и висит.
> Происходит такое не на некоторых машинах, а именно иногда, то есть
> невыключившаяся машина может в следующий раз отработать хорошо.
По идее, на p8_e2k это ещё не должно было быть http://systemd.io/RANDOM_SEEDS

В любом разе тот класс надо будет обновлять до p9_e2k, масса вкусностей
(хотя как раз по этому вопросу может и усугубиться, такая вот ухмылка судьбы).

(Ответ для gosts 87 на комментарий #6)
> У пользователя Δημητριος такая же ситуация на SimplyLinux 9.0 x86_64.
Пожалуйста, не надо смешивать даже похожим образом выглядящие баги на совершенно разных дистрибутивах и аппаратных платформах -- это только мешает.
В "см. тж." добавить можно, да.  Но вешать стоит отдельно.

>Пожалуйста, не надо смешивать даже похожим образом выглядящие баги на
> совершенно разных дистрибутивах и аппаратных платформах -- это только мешает.
> В "см. тж." добавить можно, да.  Но вешать стоит отдельно.
Если подскажете, как правильно оформить новую ошибку - буду благодарен.

За восемь лет в баге не появилось ни одного журнала с машины: ни journalctl -b -1, ни вывода с systemd.log_level=debug, о которых просили в комментариях. Без них причину перемежающегося зависания на выключении установить нельзя, а ветка p8_e2k, на которой оно наблюдалось, снята с поддержки вместе с p9_e2k; сейчас на e2k — p10_e2k с systemd 249.17-alt2.E2K.2 и sisyphus_e2k с 257.9-alt1.E2K.1, в Sisyphus — 260.4-alt2 (задание https://packages.altlinux.org/tasks/429117/).

Схожий случай на x86_64 (#39336) закрыт после того, как причина оказалась в ядре 5.4, а не в systemd; как отмечено в комментарии 7, смешивать его с этим отчётом не стоит.

Закрываю за отсутствием данных. Если на актуальной e2k-ветке машина по-прежнему иногда не выключается, заведите новый баг с journalctl -b -1 после неудачного выключения и загрузкой с systemd.log_level=debug — тогда будет с чем работать.