A stop is running for Session 1

Насколько помнится, должны быть строки типа такого, почти в конце
session-1.scope: Killing process <PID> ....
session-1.scope: Failed with result ‘timeout’ ....
В твоем выводе что то не видно Failed with result ‘timeout’ - может не тот лог?

Можно еще использовать волшебные кнопки - Alt + SysRq + d - это покажет в логах информацию о всех блокировках, которые держат устройства или файлы.
Как это делать - описывал не однократно.

EDIT - Не прав - похоже изменилось ... смотрим help Alt + SysRq + h ... и видим, что d исчезло ...
sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(v) show-blocked-tasks(w) dump-ftrace-buffer(z)
Ошибки не исчезают с опытом - они просто умнеют
igorog
При очередном зависании выключения, когда идёт таймер и ни на что не реагирует - я могу что-то сделать, чтобы в ЭТОТ момент собрать макс. лог?
Как сохранить информацию краша по максимуму именно в ЭТОТ момент?
Описывал не однократно - как и что делать - использую волшебные кнопки ... используя их мошешь даже выполнить и reboot и shutdown ...
Ошибки не исчезают с опытом - они просто умнеют
Запустил journalctl - там нет никакого упоминания о проблеммах с завершением работы, только лог загрузки.
???
Это нормально? Разве там не полный журнал? Простите за нубские вопросы. Просто у нас глубокая ночь, а это инфа на "сон грядущий". Завтра вникну.
vasek
Alt + SysRq + d
Спасибо, завтра буду вести разбор полётов.
А сейчас, - Спокойной ночи!
Давайте жить дружно! :-)
Посмотрел логи (часть вывода) … вот только зачем выложил за разные даты и время?
igorog
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Stopping timed out. Killing.
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Killing process 14585 (qemu-system-x86) with signal SIGKILL.
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Killing process 14619 (kvm-nx-lpage-re) with signal SIGKILL.
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Killing process 15784 (adb) with signal SIGKILL.
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Killing process 14609 (qemu-sy:disk$0) with signal SIGKILL.
фев 14 12:00:10 FIRE systemd[1]: session-1.scope: Killing process 14610 (n/a) with signal SIGKILL.
что можно сказать на вскидку? - похоже следовал советам и внес изменения в файл /etc/systemd/system.conf или /etc/systemd/logind.conf … так как при выключении много процессов не отвечает и их уничтожает сигнал SIGKILL … никакого timeout не видно … и что там происходит, не понятно.
Но есть один нюанс - все эти процессы, которые уничтожает SIGKILL, принадлежат FIRE systemd[1] - это что - песочница? … если да, то для начала нужно ее деактивировать и если без нее все будет нормально, то причина в ее настройке/запуске/выключении.
Но лучше эту гадость убрать вообщее … и не забудь вернуть на место настройки в файлах /etc/systemd/system.conf и /etc/systemd/logind.conf
Ошибки не исчезают с опытом - они просто умнеют
vasek
Насколько помнится, должны быть строки типа такого, почти в конце

session-1.scope: Killing process <PID> ….
session-1.scope: Failed with result ‘timeout’ ….

тоже иногда, может один раз на 10- 15 выключений такое бывает, вот крайний случай:

[acid@raccoon ~ ]$ journalctl -b -2 -p5 | grep -i kill
фев 13 16:22:16 raccoon systemd[571]: pulseaudio.service: Killing process 765 (gdbus) with signal SIGKILL.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Stopping timed out. Killing.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Killing process 622 (kwin_x11) with signal SIGKILL.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Killing process 6261 (FreezeDetector) with signal SIGKILL.
фев 13 16:22:16 raccoon systemd-logind[394]: System is powering down.
фев 13 16:22:16 raccoon sddm[419]: Authentication error: "Process crashed"
фев 13 16:22:16 raccoon sddm[419]: Auth: sddm-helper crashed (exit code 15)
фев 13 16:22:16 raccoon sddm[419]: Authentication error: "Process crashed"
фев 13 16:22:16 raccoon sddm[419]: Auth: sddm-helper exited with 15
фев 13 16:22:16 raccoon kded5[619]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
фев 13 16:22:16 raccoon polkitd[658]: Unregistered Authentication Agent for unix-session:1 (system bus name :1.18, object path /org/kde/PolicyKit1/AuthenticationAgent, locale ru_UA.UTF-8) (disconnected from bu>
фев 13 16:22:16 raccoon kded5[619]: The X11 connection broke: I/O error (code 1)
фев 13 16:22:16 raccoon udisksd[707]: udisks daemon version 2.9.4 exiting
фев 13 16:22:16 raccoon kglobalaccel5[652]: The X11 connection broke (error 1). Did the X11 server die?
фев 13 16:22:16 raccoon kactivitymanagerd[661]: The X11 connection broke (error 1). Did the X11 server die?
фев 13 16:22:16 raccoon kwin_x11[622]: The X11 connection broke: I/O error (code 1)
фев 13 16:22:16 raccoon pulseaudio[690]: ICE I/O error handler called
фев 13 16:22:16 raccoon pulseaudio[690]: X11 I/O error handler called
фев 13 16:22:16 raccoon pulseaudio[690]: X11 I/O error exit handler called, preparing to tear down X11 modules
фев 13 16:22:16 raccoon kscreen_backend_launcher[780]: The X11 connection broke (error 1). Did the X11 server die?
фев 13 16:22:16 raccoon systemd-coredump[8688]: Failed to connect to coredump service: Connection refused
фев 13 16:22:16 raccoon systemd[571]: pulseaudio.service: Main process exited, code=dumped, status=11/SEGV
фев 13 16:22:16 raccoon systemd[571]: pulseaudio.service: Killing process 765 (gdbus) with signal SIGKILL.
фев 13 16:22:16 raccoon systemd[571]: pulseaudio.service: Failed with result 'core-dump'.
фев 13 16:22:17 raccoon pulseaudio[8766]: Stale PID file, overwriting.
фев 13 16:22:17 raccoon pulseaudio[8766]: stat('/etc/pulse/default.pa.d'): Нет такого файла или каталога
фев 13 16:22:17 raccoon sddm[419]: Signal received: SIGTERM
фев 13 16:22:18 raccoon sddm[419]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
фев 13 16:22:18 raccoon systemd[1]: sddm.service: Consumed 12min 20.610s CPU time.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Stopping timed out. Killing.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Killing process 622 (kwin_x11) with signal SIGKILL.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Killing process 6261 (FreezeDetector) with signal SIGKILL.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Failed with result 'timeout'.
фев 13 16:23:46 raccoon systemd[1]: session-1.scope: Consumed 19min 10.201s CPU time.
фев 13 16:23:46 raccoon systemd[571]: app.slice: Consumed 1h 9min 46.660s CPU time.
фев 13 16:23:46 raccoon systemd[575]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8004 service=[systemd-user] terminal=[] user=[acid] ruser=[<unknown>] rhost=[<unknown>]
фев 13 16:23:46 raccoon systemd[1]: user@1000.service: Consumed 1h 12min 21.396s CPU time.
фев 13 16:23:46 raccoon systemd[1]: user-1000.slice: Consumed 1h 31min 31.607s CPU time.
фев 13 16:23:47 raccoon systemd[1]: user.slice: Consumed 1h 31min 31.607s CPU time.
фев 13 16:23:47 raccoon systemd[1]: Shutting down.
«Load universe into cannon. Aim at brain. Fire.» ©
igorog
завтра буду вести разбор полётов.
Если на десктопе система сходным образом -- задержка загрузки/выгрузки -- ведёт себя и в другой ОС (уточнить в случае дуалбута), то есть смысл проверить соединение кабелей питания присоединенных устройств. И начать прежде всего с HDD, SSD и т.п.

Буквально на неделе решил вопрос знакомому, у которого Archlinux примерно с месяц при завершении работы имел непонятные задержки. Кроме того индикация на материнской плате подмигивала разными встроенными огоньками и периодически раздавались непонятные щелчки.

Попытки наскоком решить вопрос оказались неудачными, в логах было что-то о LVM, хотя они не были созданы и т.д., и т.п. В итоге недавно система вообще стала очень странно и долго загружаться/выгружаться. В том числе и установленная мастдайка. Потребовалась скорая помощь. Я начал с проверки последних обновлений системы. Затем протестировал носители информации на ошибки штатными средствами: всё в порядке. И лишь открыв системный блок, обнаружил, что кабель питания на одном HDD присоединён неплотно (почти слетел). Хотя этот диск монтировался при загрузке, читался и тестировался.

После добросовестного присоединения кабеля все проблемы исчезли на всех ОС. Пропали посторонние звуки матплаты, исчезла индикация и прочее. Выяснилось, что перед НГ товарищ наводил порядок в системном блоке и очищая от пыли (как теперь стало ясно) задел кабель.

Пустяковый вопрос отнял кучу времени у двух человек.
Приведу еще один способ анализа - так как для уничтожения неотвечающих/зависших процессов применяется сигнал SIGKILL (или сигнал 9), то можно задействовать audit
- смотрим какие правила установлены
sudo auditctl -l
No rules
… если установлены, то лучше очистить командой: sudo auditctl -D ...
- устанавливаем следующее правило: sudo auditctl -a exit,always -S kill
проверяем: sudo auditctl -l
-a always,exit -S kill
… все работаем … и если какой то процесс будет уничтожен сигналом SIGKILL, то это можно будет увидеть в логах.

Как пример, замочим сами процесс xterm:
- узнаем PID xterm: pidof xterm --- 14900
- для наглядности (да и чтобы не утонуть в логах) запускаем journalctl -f
- уничтожаем xterm: sudo kill -9 14900
- находим в логах следующие строчки (идущие подряд)
фев 15 12:36:23 arch audit[15547]: SYSCALL arch=c000003e syscall=62 success=yes exit=0 a0=3a34 a1=9 a2=0 a3=7f8b360c0ac0 items=0 ppid=15546 pid=15547 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="kill" exe="/usr/bin/kill" key=(null)
фев 15 12:36:23 arch audit: OBJ_PID opid=14900 oauid=1000 ouid=1000 oses=1 ocomm="xterm"
и видим, что замочен процесс PID=14900 … и это xterm … при желании можно проанализировать всю расшифровку (сам уже не помню, а лезти в DOC - лень)
- если правило больше не нужно, не забываем его удалить --- sudo auditctl -D
Кстати, audit можно натравить и на другое, например, конкретный процесс или файл и др. ... но нужно его осваивать. Лично я им пользуюсь редко и знаю его слабо.

PS - audit имеет и свой лог - /var/log/audit/audit.log
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.