bebehei
commented
5 years ago Just run dunst in a terminal. What does it say?
Open hjpotter92 opened 5 years ago
bebehei
commented
5 years ago Just run dunst in a terminal. What does it say?
hjpotter92
commented
5 years ago @bebehei It starts from terminal, but not as a part of user service.
bebehei
commented
5 years ago What does
systemctl status --user dunstreport?
hjpotter92
commented
5 years ago ● dunst.service - Dunst notification daemon
Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-03-07 03:25:45 IST; 1h 33min ago
Docs: man:dunst(1)
Main PID: 8666 (code=exited, status=1/FAILURE)
Mar 07 03:25:45 hedwig systemd[709]: Starting Dunst notification daemon...
Mar 07 03:25:45 hedwig dunst[8666]: cannot open display
Mar 07 03:25:45 hedwig systemd[709]: dunst.service: Main process exited, code=exited, status=1/FAILURE
Mar 07 03:25:45 hedwig systemd[709]: dunst.service: Failed with result 'exit-code'.
Mar 07 03:25:45 hedwig systemd[709]: Failed to start Dunst notification daemon.
Duplicate of #347
hjpotter92
commented
5 years ago @bebehei I am fetching DISPLAY variable. I did go through the linked issue.
bebehei
commented
5 years ago DISPLAY variable is set, when systemctl is called?DISPLAY is definitely either unset or set to a wrong value.
hjpotter92
commented
5 years ago In the journalctl logs, I can see display value being provided to other dbus services.
Check the logs below:
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.15' (uid=1000 pid=712 comm="/usr/bin/pulseaudio --daemonize=no ")
Mar 07 06:17:49 hedwig systemd[1]: Starting RealtimeKit Scheduling Policy Service...
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 07 06:17:49 hedwig systemd[1]: Started RealtimeKit Scheduling Policy Service.
Mar 07 06:17:49 hedwig audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully called chroot.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully dropped privileges.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully limited resources.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Running.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Canary thread running.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Watchdog thread running.
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' requested by ':1.16' (uid=0 pid=713 comm="/usr/lib/rtkit-daemon ")
Mar 07 06:17:49 hedwig kernel: audit: type=1130 audit(1551919669.497:53): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig systemd[1]: Starting Authorization Manager...
Mar 07 06:17:49 hedwig polkitd[716]: Started polkitd version 0.116
Mar 07 06:17:49 hedwig polkitd[716]: Loading rules from directory /etc/polkit-1/rules.d
Mar 07 06:17:49 hedwig polkitd[716]: Loading rules from directory /usr/share/polkit-1/rules.d
Mar 07 06:17:49 hedwig polkitd[716]: Finished loading, compiling and executing 2 rules
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Mar 07 06:17:49 hedwig systemd[1]: Started Authorization Manager.
Mar 07 06:17:49 hedwig audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig kernel: audit: type=1130 audit(1551919669.594:54): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig polkitd[716]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully made thread 712 of process 712 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Supervising 1 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 1 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Successfully made thread 789 of process 712 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 2 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig dbus-daemon[679]: [session uid=1000 pid=679] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.3' (uid=1000 pid=788 comm="/usr/bin/python2 /bin/terminator ")
Mar 07 06:17:50 hedwig systemd[666]: Starting Accessibility services bus...
Mar 07 06:17:50 hedwig dbus-daemon[679]: [session uid=1000 pid=679] Successfully activated service 'org.a11y.Bus'
Mar 07 06:17:50 hedwig systemd[666]: Started Accessibility services bus.
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: dbus-daemon[796]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=788 comm="/usr/bin/python2 /bin/terminator ")
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: dbus-daemon[796]: Successfully activated service 'org.a11y.atspi.Registry'
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 2 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Successfully made thread 801 of process 712 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 3 threads of 1 processes of 1 users.I am, ofcourse, assuming that the requested by ':1.3' etc. appearing in dbus logs are the DISPLAY values,
tsipinakis
commented
5 years ago Thanks for the very detailed report and to be honest: We also have no clue what's happening here so it's basically a guessing game, but a very good opportunity to add some user documentation for this.
Some ideas that come to mind:
Debian has the following script in /etc/X11/Xsession.d/20dbus_xdg-runtime, some research shows that Xsession is executed later in the startup process so try adding that there.
If it still doesn't work try editing the systemd service file with (echo $DISPLAY $DBUS_SESSION_BUS_ADDRESS $XAUTHORITY; dunst) to see if the environment is actually being run.
Edit: Also: try setting --verbose --systemd to dbus-update-activation-environment, it'll print out the values it's setting and also try to import them into systemd.
hjpotter92
commented
5 years ago Temporarily fixed by placing exec_always --no-startup-id dunst in my i3 config.
hjpotter92
commented
5 years ago I did yet another clean installation on a different machine. This time, for dunst; I noticed that the service was disabled.
Doing a systemctl --user enable dunst and then starting it fixed this.
tsipinakis
commented
5 years ago Glad you fixed it, but this shouldn't have been necessary. We don't enable the service on purpose, dbus is supposed to start it automatically when a notification comes through.
hxmuller
commented
4 years ago I had similar problem. I am using i3wm and lightdm on Debian Bullseye
dunst is pulled in as a recommends of i3. I have been spending time learning journalctl and discovered during boot:
systemd[###]: Failed to start Dunst notification daemon.
I was getting that message twice during boot.
After much investigation, it became clear that dunst.service did not obtain the user's DISPLAY and XAUTHORITY variables. I discovered two methods, both requiring user intervention.
In the first method, both instances of the error message are eliminated.
$ systemctl --user disable dunst
This removes the link /etc/systemd/user/default.target.wants/dunst.service
$ systemctl --user --full edit dunst
Under [Service] I added:
Environment=DISPLAY=:0
Environment=XAUTHORITY=/var/run/lightdm/user_name/xauthorityAfterwards, enabled the service:
$ systemctl --user enable dunst
The dunst.service runs without error afterwards.
The second method is simpler, but only eliminates one of the errors:
This was performed on a fresh default install of dunst.
$ mkdir $HOME/.config/environment.d
$ vi $HOME/.config/environment.d/envars.confIn that file, I added the same as above:
DISPLAY=:0
XAUTHORITY=/var/run/lightdm/user_name/xauthorityIt is not necessary to enable the dunst.service as it is enabled by default for the user. One of the error messages regarding dunst failing to start will still be present, but seconds later during the boot the dunst service will start. I opted for this method a in case I require additional user services which need the environment variables.
kofm
commented
3 years ago On Arch + dwm, same problem.
Using
$ systemctl --user --full edit dunst
and adding
Environment=DISPLAY=:0
under [Service] solved the problem
hjpotter92
commented
3 years ago Faced this issue again with arch + xdm + i3 setup. I think this happens because the ~/.xinitrc does not get populated with the following snippet:
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fiwhich should actually source the following:
#!/bin/sh
systemctl --user import-environment DISPLAY XAUTHORITY
if command -v dbus-update-activation-environment >/dev/null 2>&1; then
dbus-update-activation-environment DISPLAY XAUTHORITY
fi
dsh2
commented
3 years ago I like to use dunst on remote hosts via ssh; so I think an approach via systemctl --user import-environment DISPLAY is preferable as DISPLAY might have changing values.
fwsmit
commented
3 years ago If you want to use dunst m over ssh you will only need to forward DBus. After you've done that you can just simply notify-send from your remote box. See https://serverfault.com/questions/405518/how-to-configure-d-bus-and-ssh-x-forwarding-to-prevent-ssh-from-hanging-on-exit.
dsh2
commented
3 years ago That's a nice idea, @fwSmit, I haven't though about yet. Usually, dunst is not the only X application I use on other machines, though. Still, forwarding D-Bus is probably less expensive in regard to network load, right? So, maybe even if I do need X for other applications, I should still go for D-Bus-dunst. Is that correct?
fwsmit
commented
3 years ago Still, forwarding D-Bus is probably less expensive in regard to network load, right?
Yeah not only that, but I don't think it would work that great if you X-forward dunst AND have it running on your local machine. The two might clash. Keep in mind that both X forwarding and dbus forwarding might pose a security risk when connecting to untrusted machines.
RedDofamine
commented
2 years ago Temporarily fixed by placing
exec_always --no-startup-id dunstin my i3 config.
I tried everything! Only your version worked for me.
yuceltoluyag
commented
2 years ago Faced this issue again with arch + xdm + i3 setup. I think this happens because the
~/.xinitrcdoes not get populated with the following snippet:if [ -d /etc/X11/xinit/xinitrc.d ] ; then for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do [ -x "$f" ] && . "$f" done unset f fiwhich should actually source the following:
#!/bin/sh systemctl --user import-environment DISPLAY XAUTHORITY if command -v dbus-update-activation-environment >/dev/null 2>&1; then dbus-update-activation-environment DISPLAY XAUTHORITY fi
After doing that, did you enable or disable the service again ? @hjpotter92
I disabled it seems to work fine
systemctl --user disable dunst
Vladimir-csp
commented
2 years ago Hi.
I've stumbled on a related problem. On those of my hosts where I rarely start graphical sessions, user@.session's began failing. I do not know when and how dunst got into default.target.wants, but this was the reason.
I have a different question: why at all try to start dunst via systemd? Dunst only makes sense in a particular graphical session.
Systemd --user stuff:
XDG autostart seems to be a much more fitting place to start a notification daemon.
fwsmit
commented
2 years ago You're not forced to use systemd service starting. If you want, just start it with your WM/DM or autostart upon sending a notification. Systemd can be used for starting things in a graphical environment. You have to set that up in your environment. Otherwise the service won't start. Xdg autostart could probably work and you're free to use it and document your usage for other people. I don't think dunst needs to implement something for that.
U1s2e3r4n5a6m7e
commented
2 years ago I get the same error most of the time
username@hostname ~ $ dunst
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
zsh: segmentation fault (core dumped) dunst
username@hostname ~ $$ systemctl status --user dunst.service
Vladimir-csp
commented
2 years ago Xdg autostart could probably work and you're free to use it and document your usage for other people. I don't think dunst needs to implement something for that.
Just providing a proper /etc/xdg/autostart/dunst.desktop would solve this, dunst will be started by DE or any XDG-compliant session scripts, and not by systemd, potentially outside graphical session.
LeCodingWolfie
commented
1 year ago @U1s2e3r4n5a6m7e Besides the warning given by dunst on the missing folder icon on your case; the daemon error ("Couldn't initialize X11 output", now reported at #1095) might be solved by either running:
systemctl --user import-environment DISPLAY
or through this other solution, and alike; all of which worked for me to solve that same issue.
U1s2e3r4n5a6m7e
commented
1 year ago I solved the issue with this comment back in the day. Thanks @LeCodingWolfie
C0D3D3V
commented
1 year ago I have now also tested pretty much every suggestion from here and in various other issues that all are about the same topic.
Since using SDDM as a display manager, the dunst service also starts way too early for me and with each suggestion I tested, I got a variation of errors. Most recently I got a similar error as in https://github.com/dunst-project/dunst/issues/866:
142 │ ERROR: [ get_x11_output:0065] Couldn't initialize X11 output. Aborting...
143 │ Invalid MIT-MAGIC-COOKIE-1 key
144 │ WARNING: Cannot open X11 display.
145 │ ERROR: [ get_x11_output:0065] Couldn't initialize X11 output. Aborting...
146 │ Invalid MIT-MAGIC-COOKIE-1 keyIf I start dunst while i3 is already running then there is no problem, the same way I can just then restart the service and it works. However, this did not work directly in the i3 config as autostart. Finally I decided for the following solution:
I disabled the dunst service, then I simply created a script under ~/.config/i3/keep_up_dunst.py, which I put into the autostart exec --no-startup-id "~/.config/i3/keep_up_dunst.py". This is to keep dunst always running (I also had problems before where dunst just crashed, this also helps against that :D)
This is my script I'm using, feel free to modify and using it :D
#!/usr/bin/env python
import os
import time
from datetime import datetime
import psutil
def check_if_process_is_running(process_name):
for proc in psutil.process_iter():
try:
if process_name.lower() in proc.name().lower():
return True
except (psutil.NoSuchProcess, psutil.AccessDenied, psutil.ZombieProcess):
pass
return False
LOG_PATH = '~/.dunst_log.txt'
full_log_path = os.path.expanduser(LOG_PATH)
if os.path.isfile(full_log_path):
log_file_size = os.path.getsize(full_log_path)
if log_file_size > 20000:
os.remove(full_log_path)
time.sleep(0.1)
while True:
if not check_if_process_is_running('dunst'):
with open(full_log_path, 'a+', encoding='utf-8') as fs:
fs.write(f'Starting dunst at: {datetime.now()}\n')
os.system(f"dunst --config ~/.config/dunst/dunstrc >> {LOG_PATH} 2>&1")
time.sleep(3)
Linux-NDOB
commented
1 year ago Arch Linux, AUR i3-gapps package.
Hello, my comment may be useless for a lot but useful for some others. I had the same problem exposed here and the only solution y found was to exit from i3 and log again.
I set too the command for start dunst on login in the i3 config file before exit and login again on i3-gaps and is working all fine, CTRL + R does not work, exit and login again worked for me.
bynect
commented
6 months ago Was this solved in the end?
C0D3D3V
commented
6 months ago @bynect for me it still does not work (only with my script above). But now in the log is a new message:
Feb 22 09:48:18 DerGeraet dbus-broker-launch[1816]: Service file '/usr/share//dbus-1/services/org.kde.plasma.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'.
Feb 22 09:48:18 DerGeraet dbus-broker-launch[1816]: Service file '/usr/share//dbus-1/services/org.knopwob.dunst.service' is not named after the D-Bus name 'org.freedesktop.Notifications'.
Feb 22 09:48:18 DerGeraet dbus-broker-launch[1816]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share//dbus-1/services/org.knopwob.dunst.service'I guess I will try to delete /usr/share//dbus-1/services/org.kde.plasma.Notifications.service
C0D3D3V
commented
6 months ago Removing /usr/share//dbus-1/services/org.kde.plasma.Notifications.service solved the problem for me.
I do no longer need my script and also no autostart entry in my i3 config. It just starts using dbus.
So if I would want to use in kde plasma the plasma notification service, I guess I need to find out how to set priority on dunst only in i3.
PS setting priority as explained in FAQ would probably also work. But I just removed plasma workspace, because I did not use it for ages.
I did a clean arch install with only XDM and i3 to serve as login/window managers. I have also installed dunst package; and according to arch wiki nothing else is required for it to work.
However, when trying to send notifications, I receive:
The troubleshoot section on same wiki page suggests assignment of
DISPLAYvariable. I have the following in my.xinitrc:which does exactly this:
Checking at dunst's FAQ, it mentions availability of
DBUS_SESSION_BUS_ADDRESSvariable. And to check thegdbuscommand for running notification daemons:I do have the dunst service listed in
/usr/share/dbus-1/servicesdirectory.According to this blog post; I should switch to dunst as my notification service. But I have no idea which notification service is my current one!
I do have 2 separate
dbus.servicelisted as running in mysystemctl statuslist; one in thesystem.slicetree and another inuser@1000.servicetree.Any pointers as to how should I configure my dbus daemon would be helpful,
Installation info
1.3.2 (2018-05-06)