Powiadomienia i demon powiadomień nie działa w menedżerze okien

13

Powiadomienia nie działają w samodzielnych menedżerach okien Linuksa (Openbox, Awesome WM i podobne). Próbowałem zainstalować demona powiadomień i dunst, ale wysyłanie za pomocą notify-send "something"nie powoduje wyskakującego okna.

Próbowałem uruchomić polkit-gnome-agent i uruchomić bezpośrednio demony powiadomień, ale to nie pomaga (wcześniej rozwiązałem podobny problem w ten sposób, ale teraz nic nie robi).

Nie ma żadnych oznak błędów, chyba że wysyłam trywialne powiadomienie za pomocą Pythona, a następnie otrzymuję tylko niejasny komunikat o błędzie: File "/usr/lib/python3.3/site-packages/gi/types.py", line 113, in function return info.invoke(*args, **kwargs) gi._glib.GError: Could not connect: Connection refused Trywialny program C nic nie wyświetla (na przykład brak błędu).

Używam Archlinuxa z systemd i d-bus, podejrzewam, że jest to problem z polkitem lub jakimś demonem, który nie uruchamia się przy starcie menedżera okien, ale nie mam pojęcia, co mogę spróbować ani jak mogę uzyskać bardziej znaczące komunikaty o błędach.

EDYCJA: Wziąłem stamtąd przykładowy kod: https://wiki.archlinux.org/index.php/Libnotify#Python

Dbus powinien działać, ponieważ systemd ma to jako zależność. Mam libnotifyzainstalowany - jest to pakiet, który zapewnia notify-send. Również demon powiadomień powinien zostać uruchomiony w razie potrzeby (tylko w przypadku powiadomienia), postępując zgodnie z następującym plikiem na pulpicie /usr/share/dbus-1/services/org.freedesktop.Notifications.service:

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/bin/dunst

Próbowałem nawet uruchamiać demony bezpośrednio (po prostu wykonać) i próbowałem wysyłać powiadomienia. Jeśli ktoś wie, jak mogę zdobyć więcej informacji, nie wahaj się zasugerować.

EDYCJA 2: Próbowałem uruchomić demona powiadomień z sudo: sudo notification-daemon_name &(w moim przypadku sudo dunst &) sudo notify-send something, a następnie powiadomienie działa. Ale kiedy próbuję wykonać dowolne z poprzednich działań jako użytkownik nieuprzywilejowany (co jest ważne, większość programów wysyła powiadomienia jako użytkownik nieuprzywilejowany), nic się nie pokazuje.

notification-daemon w ogóle odmawia pracy bez żadnego błędu lub ostrzeżenia.

EDYCJA 3: Oczywiście jest to problem z uprawnieniami: nie mogę wysyłać powiadomień bez dostępu do konta root. Po czystym ponownym uruchomieniu: sudo notify-send "something"działa nawet bez ręcznego uruchamiania żadnych demonów, ale co ja (i moje uruchomione programy) powinienem robić, aby móc wysyłać powiadomienia bez uprawnień roota, jak to możliwe w Gnome lub w innych pełnych środowiskach pulpitu?

IBr
źródło
1
Co oznacza „próbował zainstalować demona powiadomień”? Czy zainstalowałeś się, libnotifyponieważ zapewnia to notify-sendpolecenie (które jest wszystkim, czego potrzebujesz)?
jasonwryan
Podałeś zdecydowanie za mało informacji, aby poprawnie odpowiedzieć na to pytanie. Na podstawie jedynego komunikatu o błędzie, który podałeś, podejrzewam, że DBus nie działa, a zatem nie ma nic, z czym można się połączyć, aby wysłać powiadomienie. Jeśli podałeś kod „trywialnego powiadomienia” i dokładny błąd, możemy być w stanie zbliżyć się do odpowiedzi.
msw
Wziąłem stamtąd przykładowe kody: wiki.archlinux.org/index.php/Libnotify#Python
IBr
Miałem sukces z Dunstem. Nigdy więcej komunikatów „Odmowa połączenia”.
pokaż

Odpowiedzi:

6

Wreszcie sam rozwiązałem problem.

Zostawię instrukcje, co zrobiłem.

Problem składa się z dwóch części:

  1. Nie można uzyskać dostępu do Dbus z poziomu menedżera systemu Windows
  2. Demon powiadomień nie może odbierać wiadomości z dbus

1. rozwiązanie problemu:

Prawdziwym problemem było to, że mój menedżer systemu Windows został uruchomiony z lxdm, który z jakiegoś powodu nie łączy plików konfiguracyjnych z /etc/X11/xinit/xinitrc.dwyjątkiem sesji lxde (w LXDE dbus działa, awesome wm nie). W tym folderze istnieje plik o 30-dbusnastępującej treści:

#!/bin/bash

# launches a session dbus instance
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] && type dbus-launch >/dev/null; then
  eval $(dbus-launch --sh-syntax --exit-with-session)
fi

Ta część kodu definiuje $DBUS_SESSION_BUS_ADDRESSzmienną, która definiuje port dbus do użycia w różnych aplikacjach. echo $DBUS_SESSION_BUS_ADDRESSmoże być użyty jako proste sprawdzenie poprawności, aby sprawdzić, czy istnieje sesja dbus (powinien zwrócić plik sesji dbus).

Pliki konfiguracyjne z tego folderu można łączyć za pomocą prostego skryptu powłoki na początku sesji (kod pobrany z .xinitrc):

#!/bin/bash

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

Drugie rozwiązanie problemu:

Podczas gdy dbus działa i jest dostępny dla innych programów, nadal potrzebuje większego dostępu, aby powiadomienia działały poprawnie, więc musiałem uruchomić agenta polkit, ponieważ Awesome WM go nie ma. Wybrałem lxpolkit, ponieważ miałem już prawie pełne środowisko LXDE. W moim przypadku właśnie dodałem do mojego ~/.config/awesome/rc.luapliku: awful.util.spawn_with_shell("dex /etc/xdg/autostart/lxpolkit.desktop")z jakiegoś powodu bez tej linii odmówił domyślnego uruchomienia z lxdm.

Myślę, że agent gnome polkit również powinien działać dobrze.

IBr
źródło
1
Uwaga: Twój menedżer wyświetlania nie robi i nie powinien nic robić z .xinitrc/ Zapomniałem, jak nazywa się ten inny smak. pliki te są równoważne (który jest używany, zależy od dystrybucji) i są używane tylko podczas wywoływania startxlub xinitz konsoli. prawdopodobnie przyczyną załadowania pliku systemowego jest to, że dzieje się to w LXDE, a nie w LXDM.
strugee
Dzięki za wyjaśnienie. Wygląda na to, że muszę samodzielnie wykonać ładowanie konfiguracji.
IBr
tak, to jak powinieneś to zrobić, zależy od środowiska pulpitu / wm.
strugee
zazwyczaj wszystko, co musisz zrobić, .xinitrcto uruchomić dowolne demony działające w tle, które później nie zostaną włączone (zrobiłbyś to, gdybyś nie zrobił tego np gnome-session. za Ciebie), a następnie w ostatniej linii, execniezależnie od używanego środowiska WM / pulpitu .
strugee
0

To nie jest odpowiedź, tylko duże wyjaśnienie, które może pomóc w wygenerowaniu następnego pytania.

Dziękujemy za dodanie dodatkowych szczegółów. Prawdopodobnie masz problem z uprawnieniami, ale niestety jest to prawdopodobnie związane z uprawnieniami potrzebnymi do połączenia z gniazdem domeny DBus Unix.

Aby potwierdzić to uruchomienie jako użytkownika innego niż root:

$ strace -o /tmp/ns.out notify-send "why will this not connect"
$ grep '^connect' /tmp/ns.out
connect(4, {sa_family=AF_FILE, path=@"/tmp/dbus-6AIOJVWzCC"}, 23) = 0

poza tym prawdopodobnie dostaniesz coś takiego

connect(…) = -1 ECONNREFUSED  (Connection refused)

Dlaczego? Nie mam pojęcia. Wiem, że podsystem powiadamiania zyskał o wiele więcej uwagi w społeczności programistów GNOME, niż kiedykolwiek myślałem, że tak pozornie prosta funkcja powinna. Podejrzewam, że jakiś plik konfiguracyjny znajduje się w około zillionowych lokalizacjach konfiguracyjnych GTK, ale wiem, że to nie jest zbyt pomocne.

msw
źródło
Rzeczywiście dostałemconnect(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-WC3XySChb5"}, 23) = -1 ECONNREFUSED (Connection refused) connect(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-b3oei13hP2"}, 23) = -1 ECONNREFUSED (Connection refused)
IBr
0

Dla mnie zadziałało zainstalowanie powiadomień-osd i dunst na i3wm.

anstue
źródło