-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to start dunst notification daemon for user #611
Comments
Just run |
@bebehei It starts from terminal, but not as a part of user service. |
What does
report? |
|
Duplicate of #347 |
@bebehei I am fetching DISPLAY variable. I did go through the linked issue. |
|
In the Check the logs below:
I am, ofcourse, assuming that the |
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:
Edit: Also: try setting |
Temporarily fixed by placing |
I did yet another clean installation on a different machine. This time, for dunst; I noticed that the service was disabled. Doing a |
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. |
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:
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.
This removes the link /etc/systemd/user/default.target.wants/dunst.service
Under [Service] I added:
Afterwards, enabled the service:
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.
In that file, I added the same as above:
It 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. |
On Arch + dwm, same problem. Using
and adding
under [Service] solved the problem |
Faced this issue again with arch + xdm + i3 setup. I think this happens because the if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi which 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 |
I like to use dunst on remote hosts via ssh; so I think an approach via |
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. |
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? |
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. |
I tried everything! Only your version worked for me. |
After doing that, did you enable or disable the service again ? @hjpotter92 I disabled it seems to work fine
|
Hi. Systemd
XDG autostart seems to be a much more fitting place to start a notification daemon. |
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. |
I get the same error most of the time
Click to expand!× dunst.service - Dunst notification daemon Jun 05 16:59:32 HOSTNAME systemd[456]: Starting Dunst notification daemon...
Jun 05 16:59:33 HOSTNAME systemd[456]: dunst.service: Main process exited, code=dumped, status=5/TRAP |
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. example
|
@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:
or through this other solution, and alike; all of which worked for me to solve that same issue. |
I solved the issue with this comment back in the day. Thanks @LeCodingWolfie |
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 #866:
If 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 This is my script I'm using, feel free to modify and using it :D
|
Arch Linux, AUR i3-gapps package. Hello, my comment may be useless for a lot but useful for some others. 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. |
Was this solved in the end? |
@bynect for me it still does not work (only with my script above). But now in the log is a new message:
I guess I will try to delete |
Removing 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
DISPLAY
variable. I have the following in my.xinitrc
:which does exactly this:
Checking at dunst's FAQ, it mentions availability of
DBUS_SESSION_BUS_ADDRESS
variable. And to check thegdbus
command for running notification daemons:I do have the dunst service listed in
/usr/share/dbus-1/services
directory.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.service
listed as running in mysystemctl status
list; one in thesystem.slice
tree and another in[email protected]
tree.Any pointers as to how should I configure my dbus daemon would be helpful,
Installation info
1.3.2 (2018-05-06)
The text was updated successfully, but these errors were encountered: