Настройка dbus для pidgin

Этот путь и не будет существовать. Это вообще не путь, а имя сокета в abstract namespace. Более того, при каждом запуске иксов/сессии оно будет разное.

Либо жди kdbus, либо делай не через systemd. Идиоматично это делается через logind'шный API ингибиторов, но шеллом тут не обойдёшься — нужно ловить сигналы D-Bus.

Так даже когда я просто ввожу в консоль

# /usr/bin/purple-remote setstatus?status=online

No existing libpurple instance detected.

А под обычным работает...Начинаю думать, что тут не в systemd дело.

Потому что от рута. У него своя сессионная шина (точнее, вообще никакой сессионной шины нет).

Конечно, дело не в systemd. Дело в том, как работает dbus. Адрес твоей сессионной шины (на которой висит pidgin), по сути, известен только процессам внутри твоей сессии. От этого и нужно отталкиваться.

Ну ждем тогда kdbus.

Странно конечно, если оно не работает по дефолту, то зачем написано в ArchWiki.

Понятия не имею. Может быть, когда писали этот гайд, purple-remote соединялся с самим pidgin'ом не через дбас, а через собственный транспорт.

Как вариант, можно сделать костыль следующего вида. В свой Xsession или в /etc/X11/xinit/xinitrc.d добавь скриптец, который бы экспортировал значения переменных $DISPLAY и $DBUS_SESSION_BUS_ADDRESS в какой-нибудь файлик в /tmp. А в этом своём юните запускай скрипт, который будет читать этот файлик и, если он существует, устанавливать переменные и уже потом пинать pidgin.

P. S.: зачем ждать kdbus. В случае kdbus вместо сессионных шин (по одной на сессию) будут пользовательские (по одной на пользователя). С заранее известным адресом.

ну так рули из под обычного юзера, systemd же вроде от пользователя выполнять умеет...

Этого недостаточно. Читай тред.

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

У меня с пол пинка завелось, но я что-то там правил. Заберу ноут из сервиса и посмотрю.

Было бы отлично, жду.

Я даже и не знаю, у меня такое работает:

$ cat /etc/systemd/system/pidgin-suspend.service 
[Unit]
Description=Suspend Pidgin
Before=sleep.target
StopWhenUnneeded=true

[Service]
Type=oneshot
User=medar
RemainAfterExit=true
Environment=DISPLAY=:0
ExecStart=/usr/bin/purple-remote setstatus?status=offline
ExecStop=/usr/bin/purple-remote setstatus?status=available

[Install]
WantedBy=sleep.target

Так я такой юнит описал в ОП, тут дело в настройке dbus.

Что-то настраивал к нему дополнительно?

Не припомню больше ничего. А ты точно в строчке:

User=myuser

Да, все так.

Ну ниче, буду городить другой костыль.

На новой системе и у меня не работает( Таки на старой что-то шаманил. ТС, ты проблему решил?

pacman -S python2-dbus

Настройка dbus:

nano ~/.xprofile
echo $DBUS_SESSION_BUS_ADDRESS > ~/.dbus_session

pidgin.sh положил в /usr/lib/systemd/systemd-sleep

#!/bin/bash
#
if(pidof pidgin)
then
DBUS_SESSION_BUS_ADDRESS=`cat /home/oleg/.dbus_session` su oleg -c "/usr/bin/purple-remote setstatus?status=offline"
fi

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

У меня так заработало:

$cat /etc/systemd/system/pidgin-suspend.service

[Unit]
Description=Suspend Pidgin
Before=sleep.target
StopWhenUnneeded=true

[Service]
Type=oneshot
User=medar
RemainAfterExit=true
Environment=DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
ExecStart=/usr/bin/purple-remote setstatus?status=offline
ExecStop=/usr/bin/purple-remote setstatus?status=available

[Install]
WantedBy=sleep.target

DBUS_SESSION_BUS_ADDRESS=unix:path=

А как ты заставил dbus в path, а не в abstract?

А как ты заставил dbus в path, а не в abstract?

Ничего не делал. Это на свежеустановленном арче так.

$ pacman -Q systemd dbus
systemd 226-3
dbus 1.10.0-3