snprajwal
commented
2 years ago I don't think you should be starting dunst in any way, it is automatically started by DBus upon a notification event
Closed madipietro closed 2 years ago
snprajwal
commented
2 years ago I don't think you should be starting dunst in any way, it is automatically started by DBus upon a notification event
madipietro
commented
2 years ago I don't think you should be starting dunst in any way, it is automatically started by DBus upon a notification event
Thanks!, yeah I'm trying to figure it out, why it isn't starting automatically, what else can I try ?
snprajwal
commented
2 years ago You need to set your DISPLAY env var for dunst to be started by DBus. You have to set it manually because systemd does not inherit environment variables. Add these two lines to your i3 config
exec --no-startup-id systemctl --user import-environment DISPLAY XAUTHORITY
exec --no-startup-id dbus-update-activation-environment DISPLAY XAUTHORITYYou need to set your DISPLAY env var for dunst to be started by DBus. You have to set it manually because systemd does not inherit environment variables. Add these two lines to your i3 config
exec --no-startup-id systemctl --user import-environment DISPLAY XAUTHORITY exec --no-startup-id dbus-update-activation-environment DISPLAY XAUTHORITY
Thanks @snprajwal, the thing is I don't have that lines on my I3 config, and it was working it is really weird, also I noticed that the script /etc/X11/xinit/xinitrc.d/50-systemd-user.sh is doing that I think.
#!/bin/sh
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
systemctl --user import-environment DISPLAY XAUTHORITY
if command -v dbus-update-activation-environment >/dev/null 2>&1; then
dbus-update-activation-environment DISPLAY XAUTHORITY
fiIs this correct ?
snprajwal
commented
2 years ago As far as I know, Xorg does not source /etc/X11/xinit if it is started with startx. Using xinit has it's own weird behaviour (X11 is pretty damn broken, to be honest). For that reason, you need to manually run these commands, either in your .profile/.zprofile (depending on your shell) or in your i3 config file. I prefer doing it in the config because it keeps things cleaner.
Narrat
commented
2 years ago startx sources at least$HOME/.xinitrc. And in this file one could also place the lines regarding calling the stuff in /etc/X11/xinit/xinitrc.d/. Which should also do the trick if startx is used. Though that doesn't explain why it fails now for some reason.
Some information can be found in the wiki
snprajwal
commented
2 years ago @Narrat
Though that doesn't explain why it fails now for some reason.
Jan 29 10:14:02 Tesla dunst[3900]: CRITICAL: Cannot open X11 display.
I think this line in the logs means that $DISPLAY is not set, causing it to fail
Narrat
commented
2 years ago That's right. But my sentence was more directed on the report, that it previously worked and now is failing. :) But it isn't a new behaviour of dunst to rely on the set DISPLAY var. So either @madipietro replaced some tool (like display manager), rewrote some config or magic was at work :D That's the point that left me wondering.
madipietro
commented
2 years ago As far as I know, Xorg does not source
/etc/X11/xinitif it is started withstartx. Usingxinithas it's own weird behaviour (X11 is pretty damn broken, to be honest). For that reason, you need to manually run these commands, either in your.profile/.zprofile(depending on your shell) or in your i3 config file. I prefer doing it in the config because it keeps things cleaner.
startxsources at least$HOME/.xinitrc. And in this file one could also place the lines regarding calling the stuff in/etc/X11/xinit/xinitrc.d/. Which should also do the trick ifstartxis used. Though that doesn't explain why it fails now for some reason. Some information can be found in the wiki
I'm starting I3 using SDDM, not startX :(
That's right. But my sentence was more directed on the report, that it previously worked and now is failing. :) But it isn't a new behaviour of dunst to rely on the set
DISPLAYvar. So either @madipietro replaced some tool (like display manager), rewrote some config or magic was at work :D That's the point that left me wondering.
Yeah! that's why I'm looking for some help to see what can I debug in order to make this work again.
Narrat
commented
2 years ago Sadly, I don't know much about SDDM. Can you somewhat pinpoint the time when it stopped working? The pacman.log may then help to narrow down the selection of updated packages which may have caused this. (Hopefully you update rather frequently :D) Or did you tweak some configs?
The script /etc/X11/xinit/xinitrc.d/50-systemd-user.sh does what you think, but it needs to be sourced/executed by something. Or implemented otherwise. But dunno what SDDM does in that regard.
Nevertheless, the option mentioned by @snprajwal to add the respective lines to your i3 config should make it work again if it cannot be deduced what happened.
madipietro
commented
2 years ago Sadly, I don't know much about SDDM. Can you somewhat pinpoint the time when it stopped working? The
pacman.logmay then help to narrow down the selection of updated packages which may have caused this. (Hopefully you update rather frequently :D) Or did you tweak some configs? The script/etc/X11/xinit/xinitrc.d/50-systemd-user.shdoes what you think, but it needs to be sourced/executed by something. Or implemented otherwise. But dunno what SDDM does in that regard.Nevertheless, the option mentioned by @snprajwal to add the respective lines to your i3 config should make it work again if it cannot be deduced what happened.
Thanks @Narrat I tried that but still doesn´t work ( so weird )
On my .config/i3/config
exec --no-startup-id systemctl --user import-environment DISPLAY XAUTHORITY
exec --no-startup-id dbus-update-activation-environment DISPLAY XAUTHORITYOnly way to make it work for now on my I3 config.
exec_always --no-startup-id "/usr/bin/dunst"or
exec_always --no-startup-id "/usr/bin/systemctl --user restart dunst.service"I think I will leave it on the I3 config for now, because it works.
fwsmit
commented
2 years ago I think what's happening here is that dunst is started too early. I don't know how graphical-session.target is started for you, but it should only be started after you X session has started.
exec --no-startup-id systemctl --user import-environment DISPLAY XAUTHORITY
exec --no-startup-id dbus-update-activation-environment DISPLAY XAUTHORITYI don't think you need this. As said earlier, it's already configured in another place.
exec_always --no-startup-id "/usr/bin/dunst"This is the easiest solution. I would change exec_always into exec, though, since you cannot start a second dunst instance when one is already running. Alternatively, you can leave this line out of your config and dunst should be auto-started on the first notification.
I'll close this issue, as it seems that it works for you now.
madipietro
commented
2 years ago I think what's happening here is that dunst is started too early. I don't know how graphical-session.target is started for you, but it should only be started after you X session has started.
exec --no-startup-id systemctl --user import-environment DISPLAY XAUTHORITY exec --no-startup-id dbus-update-activation-environment DISPLAY XAUTHORITYI don't think you need this. As said earlier, it's already configured in another place.
exec_always --no-startup-id "/usr/bin/dunst"This is the easiest solution. I would change
exec_alwaysintoexec, though, since you cannot start a second dunst instance when one is already running. Alternatively, you can leave this line out of your config and dunst should be auto-started on the first notification.I'll close this issue, as it seems that it works for you now.
HI @fwsmit I have a simple setup using sddm for starting I3 if I list my units I have this
systemctl list-units --type=target ✔
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
integritysetup.target loaded active active Local Integrity Protected Volumes
local-fs-pre.target loaded active active Preparation for Local File Systems
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network.target loaded active active Network
paths.target loaded active active Path Units
remote-fs.target loaded active active Remote File Systems
slices.target loaded active active Slice Units
sockets.target loaded active active Socket Units
sound.target loaded active active Sound Card
swap.target loaded active active Swaps
sysinit.target loaded active active System Initialization
timers.target loaded active active Timer Units
veritysetup.target loaded active active Local Verity Protected Volumes
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
18 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.I think what you said here make sense, but then I suppose that the dunst unit, need to have a dependence of the graphical target, Am I right ?
I'm using this for starting dunst on my I3 config file.
exec_always --no-startup-id "/usr/bin/systemctl --user restart dunst.service"Maybe I can try to fix the systemd unit and to do a PR ?
Thanks!.
fwsmit
commented
2 years ago I think what you said here make sense, but then I suppose that the dunst unit, need to have a dependence of the graphical target, Am I right ?
No, graphical.target is started too early. I think if you want the systemd unit to work, you'll need to set up a graphical-session.target unit yourself and make sure it gets started after i3 has started. I'm not sure about the details, though, since I just let dunst be auto started upon a notification (this should work by default, unless you have another notification daemon installed, in which case dbus might start any of them).
I think the systemd unit is correct, no changes needed. The way I would recommend to start dunst is to just disable autostarting of the dunst service and let it be started by dbus upon the first notification. If for some reason you want to have multiple notification daemons installed, I would recommend putting exec dunst in your i3 config.
I guess that exec_always --no-startup-id "/usr/bin/systemctl --user restart dunst.service" would be nice if you want to reload the dunst config upon reloading the i3 config.
madipietro
commented
2 years ago I think what you said here make sense, but then I suppose that the dunst unit, need to have a dependence of the graphical target, Am I right ?
No,
graphical.targetis started too early. I think if you want the systemd unit to work, you'll need to set up a graphical-session.target unit yourself and make sure it gets started after i3 has started. I'm not sure about the details, though, since I just let dunst be auto started upon a notification (this should work by default, unless you have another notification daemon installed, in which case dbus might start any of them).I think the systemd unit is correct, no changes needed. The way I would recommend to start dunst is to just disable autostarting of the dunst service and let it be started by dbus upon the first notification. If for some reason you want to have multiple notification daemons installed, I would recommend putting
exec dunstin your i3 config.I guess that
exec_always --no-startup-id "/usr/bin/systemctl --user restart dunst.service"would be nice if you want to reload the dunst config upon reloading the i3 config.
I just have dunst, I have installed KDE but I'm not using it since I'm using I3 since a lot of time with dunst I don't have enabled the dunst.service since it's not needed I think
~ ❯ systemctl status dunst.service INT ↵
Unit dunst.service could not be found.
~ ❯ systemctl status --user dunst.service 4 ↵
○ dunst.service - Dunst notification daemon
Loaded: loaded (/usr/lib/systemd/user/dunst.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:dunst(1)That's the state of the unit by default when my system starts.
And the logs are telling this
Feb 16 12:45:59 Tesla systemd[673]: Started Dunst notification daemon.
Feb 16 12:46:09 Tesla dunst[2234]: X connection to :0 broken (explicit kill or server shutdown).
Feb 16 12:46:09 Tesla systemd[673]: dunst.service: Main process exited, code=exited, status=1/FAILUREI think that is not related to another notification daemon it's really weird. But of course using exec_always --no-startup-id "/usr/bin/systemctl --user restart dunst.service" on mi I3 config, dunst will work at the start of mi I3 and the unit will be on running state. Could be something else to debug ?
Issue description
Hello Folks, I'm looking for some help since I have dunst installed on ArchLinux with I3wm and suddenly it stopped working via Systemd while I can make it work by hand.
pkill dunst; dunst: This works./usr/bin/dunst: This works.systemctl --user restart dunst.service: This works.Installation info
1.6.1-2packageI3Minimal dunstrc
```ini [global] ### Display ### #layer = overlay fullscreen = pushback # Which monitor should the notifications be displayed on. monitor = 0 # Display notification on focused monitor. Possible modes are: # mouse: follow mouse pointer # keyboard: follow window with keyboard focus # none: don't follow anything # # "keyboard" needs a window manager that exports the # _NET_ACTIVE_WINDOW property. # This should be the case for almost all modern window managers. # # If this option is set to mouse or keyboard, the monitor option # will be ignored. follow = mouse # The geometry of the window: # [{width}]x{height}[+/-{x}+/-{y}] # The geometry of the message window. # The height is measured in number of notifications everything else # in pixels. If the width is omitted but the height is given # ("-geometry x2"), the message window expands over the whole screen # (dmenu-like). If width is 0, the window expands to the longest # message displayed. A positive x is measured from the left, a # negative from the right side of the screen. Y is measured from # the top and down respectively. # The width can be negative. In this case the actual width is the # screen width minus the width defined in within the geometry option. geometry = "0x4-25-10" # Show how many messages are currently hidden (because of geometry). indicate_hidden = yes # Shrink window if it's smaller than the width. Will be ignored if # width is 0. shrink = no # The transparency of the window. Range: [0; 100]. # This option will only work if a compositing window manager is # present (e.g. xcompmgr, compiz, etc.). transparency = 0 # The height of the entire notification. If the height is smaller # than the font height and padding combined, it will be raised # to the font height and padding. notification_height = 0 # Draw a line of "separator_height" pixel height between two # notifications. # Set to 0 to disable. separator_height = 1 # Padding between text and separator. padding = 8 # Horizontal padding. horizontal_padding = 10 # Defines width in pixels of frame around the notification window. # Set to 0 to disable. frame_width = 0 # Defines color of the frame around the notification window. frame_color = "#282a36" # Define a color for the separator. # possible values are: # * auto: dunst tries to find a color fitting to the background; # * foreground: use the same color as the foreground; # * frame: use the same color as the frame; # * anything else will be interpreted as a X color. separator_color = frame # Sort messages by urgency. sort = yes # Don't remove messages, if the user is idle (no mouse or keyboard input) # for longer than idle_threshold seconds. # Set to 0 to disable. # A client can set the 'transient' hint to bypass this. See the rules # section for how to disable this if necessary idle_threshold = 120 ### Text ### font = Monospace 14: # The spacing between lines. If the height is smaller than the # font height, it will get raised to the font height. line_height = 0 # Possible values are: # full: Allow a small subset of html markup in notifications: # bold # italic #strikethrough# underline # # For a complete reference see #I have this files on my OS.
And
/usr/share/dbus-1/services/org.knopwob.dunst.service:
/usr/lib/systemd/user/dunst.service:
At system start:
For now I'm starting dunst from mi I3 config file, but I prefer this to work in a clean way with systemd as it used to do, what can I do in order to know what is happening here ?. Thanks in advance!.