Система не хочет уходить в гибернацию с первого раза

Началось это в начале осени или в конце лета, я точно не помню. ПК перестал уходить в гибернацию с первого раза. Крайне редко уходит с первого, часто со второго, иногда с третьего и больше. Гибернацию настраивал по этой инструкции и раньше всё работало как часы.
Сейчас нажимаю на кнопку, система отключается, шуршит винтом и снова включается.
При этом на экране бывает такой текст https://imgur.com/a/W25j7gk или другой.
Вот лог попытки уйти в гибернацию https://pastebin.com/MV8Y3gib
Смущает это:
сне 05 23:18:58 192.168.100.6 systemd-sleep[13475]: sh: строка 1: terminal_output: команда не найдена
сне 05 23:18:58 192.168.100.6 systemd-sleep[13480]: sleep: нераспознанный параметр «–interruptible»
Вот ошибки https://pastebin.com/NKm15Ti1 других нет.

Возможно эти баги как-то связаны. С выключением после обновления на 6 ядро вообще стали твориться странности…

https://bugzilla.opensuse.org/show_bug.cgi?id=1203519

https://bugzilla.suse.com/show_bug.cgi?id=1204717

Похоже совсем не то.

у вас есть pipewire, который не может найти устройство, и pcloud, который падает - эти два процесса считаются не заснувшими, поэтому переход в гибернацию и не удаётся

1 Like

А как выяснить какое устройство нужно pipewire? А pcloud после спячки жив, он давно уже стоит и раньше он не мешал спячке.

pcloud и clipto падают и перезапускаются при попытке гибернации, возможно, речь про эти два процесса, которые не удалось усыпить. То, что раньше работало - не показатель, они ведь и обновиться могли за это время.

Либо речь не про них, а про pipewire, не находящий устройство, и nscd, не находящий файл, судя по логам:

во второй попытке опять pipewire не может к устройству обратиться:

Но в этот раз уже засыпает.

task:pcloud state:D
task:clipto state:D

state D == Uninterruptible sleep. Обычно связан с вводом выводом. В обоих случаях стек связан с подкачкой с диска, да еще через FUSE

сне 05 23:19:21 192.168.100.6 kernel:  ? fuse_simple_background+0xf8/0x160 [fuse 7fc82fc7a4783ae17b3a03cc7eca286fef64f2cc]
сне 05 23:19:21 192.168.100.6 kernel:  ? fuse_readahead+0x478/0x520 [fuse 7fc82fc7a4783ae17b3a03cc7eca286fef64f2cc]
...
сне 05 23:19:21 192.168.100.6 kernel:  handle_mm_fault+0xae/0x290

Это совершенно нормальная ситуация, никакого криминала здесь нет (процессы ждут завершения операции ввода/вывода, а процесс FUSE, который должен был бы их обработать, вполне может уже быть приостановлен).

Поскольку ввод/вывод был завершен, теперь ничего не мешает.

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

Открыт только Вивальди с 3 вкладками и оперативки 16 Гб. А раньше, когда проблемы не было, вкладок было под 30 и другие приложения были открыты.

Не было времени написать. Я закрыл все фоновые приложения висящие в трее и гибернация стала срабатывать с первого раза. Не было времени разбираться кто виноват. Просто пару дней жил без приложений в трее и всё было норм.
Но внезапно гибернация сломалась совсем. Теперь вообще ни с какой попытки не хочет уходить в сон, даже с закрытыми приложениями в трее. Были обновления…
Вот лог kot@192:~$ sudo journalctl --since "2023-01-31 06:07:00" - Pastebin.com вот это смущает:

сту 31 06:08:18 localhost.localdomain systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'.
сту 31 06:08:18 localhost.localdomain systemd[1]: Failed to start Hibernate.
сту 31 06:08:18 localhost.localdomain systemd[1]: Dependency failed for System Hibernation.
сту 31 06:08:18 localhost.localdomain systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'.
type or paste code here

Критические ошибки kot@192:~$ sudo journalctl --since "2023-01-31 06:07:00" -p 2 - Pastebin.com
Просто ошибки kot@192:~$ sudo journalctl --since "2023-01-31 06:07:00" -p 3 - Pastebin.com
Предупреждения kot@192:~$ sudo journalctl --since "2023-01-31 06:07:00" -p 4 - Pastebin.com

Поиск по первой строке (даже несмотря на то, что она обрезана) выдает достаточно много результатов. У меня NVIDIA нет, так что прокомментировать их не могу.

1 Like

Если бы ещё понимать что там пишут.

Из того что понял, это драйверы нвидиа виноваты? Fedora 34 KDE unable to suspend after nvidia driver update - Ask Fedora

Как следует из этого обсуждения, их просто нужно правильно приготовитьнастроить.

Это помогло
• sudo systemctl enable nvidia-suspend.service
• sudo systemctl enable nvidia-hibernate.service
• sudo systemctl enable nvidia-resume.service

Что-то совсем с этими ядрами и дровами плохо стало, прилетело новое ядро и система не запускает графику, с предыдущим ядром норм. Ну да ладно, подожду следующего ядра. Но есть другой вопрос. Гибернация теперь работает норм, но не работает скрипт который у меня лежит в /usr/lib/systemd/system-sleep/ – он должен отрабатывать при уходе в гибернацию м при просыпании, но сейчас стал работать только при просыпании. Я так понимаю это связано с нвидиа? Может я не всё выполнил по ссылке?

Я так понимаю это должно вернуть старый способ управления спячкой и мой скрипт будет работать как положено, но я не понимаю что куда прописывать:

or recreate a conf file in either modprobe.d folder (/etc or /usr/lib) with NVreg_PreserveVideoMemoryAllocations=0 to enable the old powersave mode with the coming nvidia driver updates.

Нашёл закомментированную строчку #options nvidia NVreg_OpenRmEnableUnsupportedGpus=1 в файле /usr/lib/modprobe.d/50-nvidia-default.conf. Поставить её в ноль и будет старый режим управления сном? А вообще что даёт новый?