A stop is running for Session 1

vasek	# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 2 недели назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Насколько помнится, должны быть строки типа такого, почти в конце `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)` Ошибки не исчезают с опытом - они просто умнеют

# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 2 недели назад)

Сообщения: 11320

Участник с: 17 февраля 2013

Насколько помнится, должны быть строки типа такого, почти в конце

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)

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 3 недели назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	igorog При очередном зависании выключения, когда идёт таймер и ни на что не реагирует - я могу что-то сделать, чтобы в ЭТОТ момент собрать макс. лог? Как сохранить информацию краша по максимуму именно в ЭТОТ момент? Описывал не однократно - как и что делать - использую волшебные кнопки ... используя их мошешь даже выполнить и reboot и shutdown ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 3 недели назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

igorog
При очередном зависании выключения, когда идёт таймер и ни на что не реагирует - я могу что-то сделать, чтобы в ЭТОТ момент собрать макс. лог?
Как сохранить информацию краша по максимуму именно в ЭТОТ момент?

Описывал не однократно - как и что делать - использую волшебные кнопки ... используя их мошешь даже выполнить и reboot и shutdown ...

Ошибки не исчезают с опытом - они просто умнеют

igorog	# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 3 недели назад)
Темы: 12 Сообщения: 136 Участник с: 22 июля 2018	Запустил journalctl - там нет никакого упоминания о проблеммах с завершением работы, только лог загрузки. ??? Это нормально? Разве там не полный журнал? Простите за нубские вопросы. Просто у нас глубокая ночь, а это инфа на "сон грядущий". Завтра вникну. vasek Alt + SysRq + d Спасибо, завтра буду вести разбор полётов. А сейчас, - Спокойной ночи! Давайте жить дружно! :-)

igorog

# 6 месяцев, 3 недели назад (отредактировано 6 месяцев, 3 недели назад)

Темы: 12

Сообщения: 136

Участник с: 22 июля 2018

Запустил journalctl - там нет никакого упоминания о проблеммах с завершением работы, только лог загрузки.
???
Это нормально? Разве там не полный журнал? Простите за нубские вопросы. Просто у нас глубокая ночь, а это инфа на "сон грядущий". Завтра вникну.

vasek
Alt + SysRq + d

Спасибо, завтра буду вести разбор полётов.
А сейчас, - Спокойной ночи!

Давайте жить дружно! :-)

vasek	# 6 месяцев, 2 недели назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Посмотрел логи (часть вывода) … вот только зачем выложил за разные даты и время? 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

# 6 месяцев, 2 недели назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Посмотрел логи (часть вывода) … вот только зачем выложил за разные даты и время?

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

Ошибки не исчезают с опытом - они просто умнеют

acid_raccoon	# 6 месяцев, 2 недели назад (отредактировано 6 месяцев, 2 недели назад)
Темы: 9 Сообщения: 102 Участник с: 08 мая 2020	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.» ©

acid_raccoon

# 6 месяцев, 2 недели назад (отредактировано 6 месяцев, 2 недели назад)

Темы: 9

Сообщения: 102

Участник с: 08 мая 2020

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.» ©

vall	# 6 месяцев, 2 недели назад
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	igorog завтра буду вести разбор полётов. Если на десктопе система сходным образом -- задержка загрузки/выгрузки -- ведёт себя и в другой ОС (уточнить в случае дуалбута), то есть смысл проверить соединение кабелей питания присоединенных устройств. И начать прежде всего с HDD, SSD и т.п. Буквально на неделе решил вопрос знакомому, у которого Archlinux примерно с месяц при завершении работы имел непонятные задержки. Кроме того индикация на материнской плате подмигивала разными встроенными огоньками и периодически раздавались непонятные щелчки. Попытки наскоком решить вопрос оказались неудачными, в логах было что-то о LVM, хотя они не были созданы и т.д., и т.п. В итоге недавно система вообще стала очень странно и долго загружаться/выгружаться. В том числе и установленная мастдайка. Потребовалась скорая помощь. Я начал с проверки последних обновлений системы. Затем протестировал носители информации на ошибки штатными средствами: всё в порядке. И лишь открыв системный блок, обнаружил, что кабель питания на одном HDD присоединён неплотно (почти слетел). Хотя этот диск монтировался при загрузке, читался и тестировался. После добросовестного присоединения кабеля все проблемы исчезли на всех ОС. Пропали посторонние звуки матплаты, исчезла индикация и прочее. Выяснилось, что перед НГ товарищ наводил порядок в системном блоке и очищая от пыли (как теперь стало ясно) задел кабель. Пустяковый вопрос отнял кучу времени у двух человек.

vall

# 6 месяцев, 2 недели назад

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

igorog
завтра буду вести разбор полётов.

Если на десктопе система сходным образом -- задержка загрузки/выгрузки -- ведёт себя и в другой ОС (уточнить в случае дуалбута), то есть смысл проверить соединение кабелей питания присоединенных устройств. И начать прежде всего с HDD, SSD и т.п.

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

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

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

Пустяковый вопрос отнял кучу времени у двух человек.

vasek	# 6 месяцев, 2 недели назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Приведу еще один способ анализа - так как для уничтожения неотвечающих/зависших процессов применяется сигнал 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 Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 месяцев, 2 недели назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Приведу еще один способ анализа - так как для уничтожения неотвечающих/зависших процессов применяется сигнал 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

Ошибки не исчезают с опытом - они просто умнеют