Fedora 18, XBMC - по-отдельности все работает, вместе - suspend вешает систему
От: Pzz Россия https://github.com/alexpevzner
Дата: 07.11.13 11:11
Оценка:
Имеется HTPC на базе такой вот симпатичной коробочки (Zotac ZBOX ID83), унутри у нее линух (Fedora 18) а в нём — XBMC.

XBMC настроен отправлять систему в suspend при нажатии на соответствующую кнопку на пульте, а так же если она ничего полезного не делает последние сколько-то времени.

До поры до времени все работало, как из пушки. Потом при уходе в suspend коробочка стала время от времени зависать. Потом стала зависать постоянно. При этом, что удивительно, команда pm-suspend работает вполне надежно, а вот засыпание по команде от XBMC не работает.

Я поразбирался во всем этом хозяйстве, и выяснил, что XBMC посылает через d-bus команду "поспать" к systemd-logind, он там коммуницирует (поди, опять через d-bus) с systemd, systemd запускает "сервис" systemd-suspend.service, и кончается все в итоге вызовом /usr/lib/systemd/systemd-sleep suspend, крошечной програмки, которая, собственно, говорит ядру "спать".

В общем, архитектура умереть-не встать, без поллитры не поймешь, да и с поллитрой тоже.

Причем, что особенно удивительно, если напрямую попросить systemd запустить засыпательный "сервис", то тоже все работает. А вот через XBMC — нет.

В логах апдейтов ничего особо интересного нет, кроме апдейтов ядра. Но как апдейты ядра могли сломать засыпание "сложным путем", через systemd, не сломав засыпание через pm-suspend, мне не понятно.

Я временно выкрутился, повесив на соответствующую кнопку пульта вызов sudo pm-suspend (это была та еще песня, как вго вешать), но в итоге лишился автоматического засыпания.

Куда копать дальше, идей нет. Никто с подобным не сталкивался?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.