% rpm -ql dbus | grep /lib/systemd/user/dbus.socket || echo 'Where?' Where? Из-за этого в системах на базе systemd пользовательские юниты не в курсе про "session bus" своего пользователя и не могут запуститься, а dbus-daemon запускается вне какого-либо контекста. В gear-репозитории они, кстати, присутствуют [1] Воспроизводится на сегодняшнем сизифе и на simply 8.2.0. [1] http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=tree;f=bus/systemd-user;h=a69e87cebe31f92976a4b3a57c01539782eb4828;hb=09034d25d08c67c534f64e96c3c59e782823dee1
dbus-1.10.20-alt1.S1 -> sisyphus: Wed Feb 07 2018 Valery Inozemtsev <shrek@altlinux.ru> 1.10.20-alt1.S1 - enable user session (closes: #34515)
Created attachment 7382 [details] Теперь войти в Mate на p8 невозможно Относительно коммита 5ca26820aa4e6fab6e5bd2c17bb30fa03eb0327c в p8. Такая вот ошибка стабильно воспроизводится при создании образов (WS/p8) через m-p после 16.10 MSK, при том, что никаких изменений в профиль m-p не вносилось. Судя по логам, systemd ругается на отсутствие шины от dbus, но проблема решается удалением в отдельной рутовой консоли пакетов ConsoleKit2 и ConsoleKit2-x11 с последующим перезапуском lightdm. После чего можно нормально залогиниться в Mate.
(In reply to comment #2) > Created an attachment (id=7382) [details] > Теперь войти в Mate на p8 невозможно > > Относительно коммита 5ca26820aa4e6fab6e5bd2c17bb30fa03eb0327c в p8. Такая вот > ошибка стабильно воспроизводится при создании образов (WS/p8) через m-p после > 16.10 MSK, при том, что никаких изменений в профиль m-p не вносилось. Судя по > логам, systemd ругается на отсутствие шины от dbus, но проблема решается > удалением в отдельной рутовой консоли пакетов ConsoleKit2 и ConsoleKit2-x11 с > последующим перезапуском lightdm. После чего можно нормально залогиниться в > Mate. Это лучше в отдельный багрепорт на ветку p8.
отключено, пока не разберемся с mate
dbus-1.10.24-alt2.S1 -> sisyphus: Thu Feb 08 2018 Valery Inozemtsev <shrek@altlinux.ru> 1.10.24-alt2.S1 - reenable user session (closes: #34515)
(В ответ на комментарий №5) > dbus-1.10.24-alt2.S1 -> sisyphus: > > Thu Feb 08 2018 Valery Inozemtsev <shrek@altlinux.ru> 1.10.24-alt2.S1 > - reenable user session (closes: #34515) Поскольку путь до systemctl неправильный, -- ничего не изменилось. dbus.socket: Executable /usr/bin/systemctl missing, skipping: No such file or directory $ grep Exec /usr/lib/systemd/user/dbus.socket ExecStartPost=-/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus
dbus-1.10.24-alt3.S1 -> sisyphus: Wed Feb 14 2018 Valery Inozemtsev <shrek@altlinux.ru> 1.10.24-alt3.S1 - fixed systemctl path (closes: #34515)
на самом деле, DBUS_SESSION_BUS_ADDRESS все равно приезжала пользователю, из /etc/X11/xinit.d/00-start-message-bus.sh Я так понимаю, что пользовательский dbus.service и /etc/X11/xinit.d/00-start-message-bus.sh делают одно и тоже. Не будет ли попыток два раза стартануть пользовательский dbus? мне кажется это стоит предусмотреть в /etc/X11/xinit.d/00-start-message-bus.sh
извиняюсь, был не прав,в /etc/X11/xinit.d/00-start-message-bus.sh уже есть проверка.