После возобновления из спящего режима зависает намертво

McG	# 4 года, 11 месяцев назад
Темы: 0 Сообщения: 60 Участник с: 30 августа 2014	Вывод `journalctl -b -u systemd-suspend.service` что говорит?

assertion9	# 4 года, 11 месяцев назад
Темы: 4 Сообщения: 15 Участник с: 13 апреля 2019	McG journalctl -b -u systemd-suspend.service `-- Logs begin at Wed 2019-04-24 .... -- No entries --`

assertion9

# 4 года, 11 месяцев назад

Темы: 4

Сообщения: 15

Участник с: 13 апреля 2019

McG
journalctl -b -u systemd-suspend.service


-- Logs begin at Wed 2019-04-24 ....
-- No entries --

McG	# 4 года, 11 месяцев назад
Темы: 0 Сообщения: 60 Участник с: 30 августа 2014	У меня `-- Logs begin at Tue 2019-04-30 10:44:38 +05, end at Tue 2019-04-30 13:20:58 +05. -- ...skipping... апр 30 13:07:53 arch systemd[1]: Starting Suspend... апр 30 13:07:53 arch systemd-sleep[3904]: Suspending system... апр 30 13:10:27 arch systemd-sleep[3904]: System resumed. апр 30 13:10:27 arch systemd[1]: systemd-suspend.service: Succeeded. апр 30 13:10:27 arch systemd[1]: Started Suspend.`

McG

# 4 года, 11 месяцев назад

Темы: 0

Сообщения: 60

Участник с: 30 августа 2014

У меня

-- Logs begin at Tue 2019-04-30 10:44:38 +05, end at Tue 2019-04-30 13:20:58 +05. --
...skipping...
апр 30 13:07:53 arch systemd[1]: Starting Suspend...
апр 30 13:07:53 arch systemd-sleep[3904]: Suspending system...
апр 30 13:10:27 arch systemd-sleep[3904]: System resumed.
апр 30 13:10:27 arch systemd[1]: systemd-suspend.service: Succeeded.
апр 30 13:10:27 arch systemd[1]: Started Suspend.

McG	# 4 года, 11 месяцев назад
Темы: 0 Сообщения: 60 Участник с: 30 августа 2014	`-- Logs begin at Wed 2019-04-24 ....` Посвежее логов нет?

assertion9	# 4 года, 11 месяцев назад
Темы: 4 Сообщения: 15 Участник с: 13 апреля 2019	McG `-- Logs begin at Wed 2019-04-24 ....` Посвежее логов нет? Только что пробовал systemctl suspend и если подождать 3 секунды без нажатия любой клавиши и снова journalctl вывод такой же как и у вас в точности

vasek	# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)
Темы: 47 Сообщения: 11743 Участник с: 17 февраля 2013	В части сообщений об ошибках клавиатуры - если клавиша не определяется или имеет проблемы, то в dmsg будет сообщение, типа (как у тебя) `atkbd serio0: Unknown key released (translated set 2, code 0x7c on isa0060/serio0). atkbd serio0: Use 'setkeycodes 7c <keycode>' to make it known.` В данном случае не определяется клавиша, имеющая сканкод 7c, но это, имхо, не должно влиять на зависание (точнее ядро не знает какой кейкоде соответствует сканкоде 7c и предлагает установить это соответствие используя утилиту setkeycodes). С этим занимайся отдельно. В части проблемы с X-ми - привожу цитату (перевод) юзера, который столкнулся с эим Я подтвердил, что эта проблема вызвана сбоем сервера Xorg с SIGBUS. Сбой сервера Xorg и systemd-logind создает новый сеанс входа в систему. Сбой сервера Xorg из-за чрезмерного количества запросов от at-spi-bus-launcher . Перед каждым сбоем в журнале systemd регистрировались такие сообщения: at-spi-bus-launcher[31720]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" at-spi-bus-launcher[31720]: after 8065 requests (8065 known processed) with 0 events remaining. Кажется, что это документированная проблема, что Xorg падает, когда получает чрезмерное количество запросов без интервала. Чтобы обойти эту ошибку, необходимы 2 шага: 1. Удалить пакет at-spi2-core 2. Добавьте export NO_AT_BRIDGE=1 в .profile , чтобы приложения GTK не жаловались на отсутствие шины доступности Xorg никогда не рушился после этого обходного пути, и, следовательно, после возобновления приостановки не было автоматического выхода из системы. Я подал отчет об ошибке против at-spi на Gnome BugZilla. Но не тут то было `Когда я думаю, что я пригвоздил эту проблему, она снова укусила меня :-(. Сама проблема действительно вызвана сбоем сервера Xorg с SIGBUS, но первопричиной аварии не является ошибочное поведение при запуске шины .` Окончательно он решил проблему переходом на uxa. Если не боишься экспериментов, то предлагаю удалить пакет at-spi2-core, как прописано выше (с пропиской export NO_AT_BRIDGE=1 в .profile) Поставить пакет обратно можно всегда. Но хотя бы проверить - в этом ли причина. Конечно, если боишься и мало опыта, то лучше не делать ... хотя, имхо, проблем вроде бы быть не должно. Edit 1 - хотя можно и не удалять - встретилось такое решение для Archlinux - Disable at spi2 service start И для проверки это думаю наиболее лучший вариант, только вместо rm лучше переименовать /usr/share/dbus-1/accessibility-services/org.a11y.* PS - Хотя что то слабо верится, что в этом случае at-spi-bus-launcher не будет запускаться …. но проверять не хочется. Если будешь пробовать этот вариант, то желательно проверить запущена ли будет эта приблуда. По чему слабо верится - в файлах /etc/xdg/autostart/at-spi-dbus-bus.desktop и /usr/lib/systemd/user/at-spi-dbus-bus.service прописан запуск at-spi-bus-launcher … а потому, имхо, надежнее удалить этот at-spi2-core Проверил, все работает - описал ниже Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)

Темы: 47

Сообщения: 11743

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

В части сообщений об ошибках клавиатуры - если клавиша не определяется или имеет проблемы, то в dmsg будет сообщение, типа (как у тебя)

atkbd serio0: Unknown key released (translated set 2, code 0x7c on isa0060/serio0).
atkbd serio0: Use 'setkeycodes 7c <keycode>' to make it known.

В данном случае не определяется клавиша, имеющая сканкод 7c, но это, имхо, не должно влиять на зависание (точнее ядро не знает какой кейкоде соответствует сканкоде 7c и предлагает установить это соответствие используя утилиту setkeycodes). С этим занимайся отдельно.

В части проблемы с X-ми - привожу цитату (перевод) юзера, который столкнулся с эим

Я подтвердил, что эта проблема вызвана сбоем сервера Xorg с SIGBUS. Сбой сервера Xorg и systemd-logind создает новый сеанс входа в систему.
Сбой сервера Xorg из-за чрезмерного количества запросов от at-spi-bus-launcher . Перед каждым сбоем в журнале systemd регистрировались такие сообщения:
at-spi-bus-launcher[31720]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
at-spi-bus-launcher[31720]:       after 8065 requests (8065 known processed) with 0 events remaining.
Кажется, что это документированная проблема, что Xorg падает, когда получает чрезмерное количество запросов без интервала.
Чтобы обойти эту ошибку, необходимы 2 шага:
    1. Удалить пакет at-spi2-core
    2. Добавьте export NO_AT_BRIDGE=1 в .profile , чтобы приложения GTK не жаловались на отсутствие шины доступности
Xorg никогда не рушился после этого обходного пути, и, следовательно, после возобновления приостановки не было автоматического выхода из системы.
Я подал отчет об ошибке против at-spi на Gnome BugZilla.

Но не тут то было

Когда я думаю, что я пригвоздил эту проблему, она снова укусила меня :-(. Сама проблема действительно вызвана сбоем сервера Xorg с SIGBUS, но первопричиной аварии не является ошибочное поведение при запуске шины .

Окончательно он решил проблему переходом на uxa.
Если не боишься экспериментов, то предлагаю удалить пакет at-spi2-core, как прописано выше (с пропиской export NO_AT_BRIDGE=1 в .profile)
Поставить пакет обратно можно всегда. Но хотя бы проверить - в этом ли причина.
Конечно, если боишься и мало опыта, то лучше не делать ... хотя, имхо, проблем вроде бы быть не должно.

Edit 1 - хотя можно и не удалять - встретилось такое решение для Archlinux - Disable at spi2 service start
И для проверки это думаю наиболее лучший вариант, только вместо rm лучше переименовать /usr/share/dbus-1/accessibility-services/org.a11y.*

PS - Хотя что то слабо верится, что в этом случае at-spi-bus-launcher не будет запускаться …. но проверять не хочется. Если будешь пробовать этот вариант, то желательно проверить запущена ли будет эта приблуда.
По чему слабо верится - в файлах /etc/xdg/autostart/at-spi-dbus-bus.desktop и /usr/lib/systemd/user/at-spi-dbus-bus.service прописан запуск at-spi-bus-launcher … а потому, имхо, надежнее удалить этот at-spi2-core
Проверил, все работает - описал ниже

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

vasek	# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)
Темы: 47 Сообщения: 11743 Участник с: 17 февраля 2013	Все-таки не поленился проверил процедуру, описанную в Edit 1 предыдущего поста - все работает - переместил /usr/share/dbus-1/accessibility-services/org.a11y.* в другое место - прописал в .xinitrc - export NO_AT_BRIDGE=1 (можно и в .xprofile) - pacman.conf не редактировал - для проверки это лишнее - убивать процесс at-spi-bus-launcher не стал, а просто перегрузился (чтобы проверить будет ли автозагрузка этой приблуды) - проверяем pidof at-spi-bus-launcher …… пусто ….. - вернул файл /usr/share/dbus-1/accessibility-services/org.a11y.* на место и проверяем pidof at-spi-bus-launcher 2046 Если вывод пустой, то нужно запустить вручную - /usr/lib/at-spi-bus-launcher --launch-immediately Можешь пробовать. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)

Темы: 47

Сообщения: 11743

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

Все-таки не поленился проверил процедуру, описанную в Edit 1 предыдущего поста - все работает
- переместил /usr/share/dbus-1/accessibility-services/org.a11y.* в другое место
- прописал в .xinitrc - export NO_AT_BRIDGE=1 (можно и в .xprofile)
- pacman.conf не редактировал - для проверки это лишнее
- убивать процесс at-spi-bus-launcher не стал, а просто перегрузился (чтобы проверить будет ли автозагрузка этой приблуды)
- проверяем
pidof at-spi-bus-launcher
…… пусто …..
- вернул файл /usr/share/dbus-1/accessibility-services/org.a11y.* на место и проверяем
pidof at-spi-bus-launcher
2046
Если вывод пустой, то нужно запустить вручную - /usr/lib/at-spi-bus-launcher --launch-immediately

Можешь пробовать.

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

vs220	# 4 года, 11 месяцев назад
Темы: 25 Сообщения: 8493 Участник с: 16 августа 2009	vasek Disable at spi2 service start Дополню к NoExtract `#удаление поддержки инвалидов at-spi NoExtract = usr/share/dbus-1/services/org.a11y.* usr/share/dbus-1/accessibility-services/org.a11y.* usr/lib/systemd/user/at-spi-dbus-bus.service`

vs220

# 4 года, 11 месяцев назад

Темы: 25

Сообщения: 8493

Участник с: 16 августа 2009

vasek
Disable at spi2 service start

Дополню к NoExtract

#удаление поддержки инвалидов at-spi
NoExtract = usr/share/dbus-1/services/org.a11y.*  usr/share/dbus-1/accessibility-services/org.a11y.*  usr/lib/systemd/user/at-spi-dbus-bus.service

assertion9	# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)
Темы: 4 Сообщения: 15 Участник с: 13 апреля 2019	vasek - вернул файл /usr/share/dbus-1/accessibility-services/org.a11y.* на место и проверяем pidof at-spi-bus-launcher Возвращать файл на место смысла нет? Повторил всё в точности кроме добавления в pacman.conf, всё такая же история. pidof at-spi-bus-launcher пустой, в .xinitrc добавил export. Удалить at-spi2-atk не получается полностью `:: gtk3: removing at-spi2-atk breaks dependency 'at-spi2-atk'` vs220 vasek Disable at spi2 service start Дополню к NoExtract `#удаление поддержки инвалидов at-spi NoExtract = usr/share/dbus-1/services/org.a11y.* usr/share/dbus-1/accessibility-services/org.a11y.* usr/lib/systemd/user/at-spi-dbus-bus.service` Добавление в pacman.conf обязательно для отключение обновления at-spi или лучше удалить и не прописывать строку?

assertion9

# 4 года, 11 месяцев назад (отредактировано 4 года, 11 месяцев назад)

Темы: 4

Сообщения: 15

Участник с: 13 апреля 2019

vasek
- вернул файл /usr/share/dbus-1/accessibility-services/org.a11y.* на место и проверяем
pidof at-spi-bus-launcher

Возвращать файл на место смысла нет?

Повторил всё в точности кроме добавления в pacman.conf, всё такая же история.

pidof at-spi-bus-launcher

пустой, в .xinitrc добавил export.

Удалить at-spi2-atk не получается полностью

 :: gtk3: removing at-spi2-atk breaks dependency 'at-spi2-atk'

vs220

vasek
Disable at spi2 service start

Дополню к NoExtract

#удаление поддержки инвалидов at-spi
NoExtract = usr/share/dbus-1/services/org.a11y.*  usr/share/dbus-1/accessibility-services/org.a11y.*  usr/lib/systemd/user/at-spi-dbus-bus.service

Добавление в pacman.conf обязательно для отключение обновления at-spi или лучше удалить и не прописывать строку?

vs220	# 4 года, 11 месяцев назад
Темы: 25 Сообщения: 8493 Участник с: 16 августа 2009	assertion9 не прописывать строку? Если не прописать то файлы по новому запишутся при обновлении