Fails to start on system start (exit-code, status 1/FAILURE)

[mpaccione]

Dunst Version: 1.41 Kubuntu 20.10 Kernel 5.8.0-53-generic

Installed via sudo apt install dunst and then downloaded via wget and moved the configuration folder over.

I am unable to have dunst run at startup. In console typing dunst works. When doing so it outputs this in the console:

WARNING: Unknown mouse action value: 'do_action, close_current'
Xlib:  extension "XINERAMA" missing on display ":0".
WARNING: Could not get xinerama screen info. Falling back to single monitor mode.
Xlib:  extension "RANDR" missing on display ":0".

I presumed that it was a display detection problem on startup so I added an Environment value to set the display to :0 in the system service file for Dunst. I then reloaded the daemons. On Reboot it doesn't work and checking the systemctl --user status dunst.service shows this:

● dunst.service - Dunst notification daemon
     Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2021-05-13 22:30:19 PDT; 13min ago
       Docs: man:dunst(1)
    Process: 2192 ExecStart=/usr/bin/dunst (code=exited, status=1/FAILURE)
   Main PID: 2192 (code=exited, status=1/FAILURE)

May 13 22:30:19 mpaccione systemd[2185]: Starting Dunst notification daemon...
May 13 22:30:19 mpaccione systemd[2185]: dunst.service: Main process exited, code=exited, status=1/FAILURE
May 13 22:30:19 mpaccione systemd[2185]: dunst.service: Failed with result 'exit-code'.
May 13 22:30:19 mpaccione systemd[2185]: Failed to start Dunst notification daemon.

However in running systemctl --user start dunst.service and then checking the status I see the following:

● dunst.service - Dunst notification daemon
     Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-05-13 23:01:47 PDT; 8s ago
       Docs: man:dunst(1)
   Main PID: 5014 (dunst)
     CGroup: /user.slice/user-1000.slice/[email protected]/dunst.service
             └─5014 /usr/bin/dunst

May 13 23:01:47 mpaccione systemd[2203]: Starting Dunst notification daemon...
May 13 23:01:47 mpaccione dunst[5014]: WARNING: Unknown mouse action value: 'do_action, close_current'
May 13 23:01:47 mpaccione dunst[5014]: Xlib:  extension "XINERAMA" missing on display ":0".
May 13 23:01:47 mpaccione dunst[5014]: WARNING: Could not get xinerama screen info. Falling back to s>
May 13 23:01:47 mpaccione dunst[5014]: Xlib:  extension "RANDR" missing on display ":0".
May 13 23:01:47 mpaccione systemd[2203]: Started Dunst notification daemon.

I need this to be operating as a system service or at the very least on system startup. I've tried configuring a script to work at startup with the above command using the kubuntu startup script executor but it doesn't work. Unsure if that is bugged as well.

Any help is appreciated, thanks!

[fwsmit]

Let's first debug running dunst from the terminal. It seems like Dunst cannot find some x extensions, so let's see if they are installed: xdpyinfo -queryExtensions. I would expect them to be installed by default, but I want to be sure. If it lists all extensions that Dunst says are missing you could try compiling and running the latest Dunst version and see if that works better.

If that doesn't work, please provide the debug output of Dunst 1.6.1 with ./dunst -verbosity debug.

[mpaccione]

Hello fwSmit, thanks for your assistance. I had read somewhere that the project was no longer maintained but it looks to be untrue!

Here is the output of querying the extensions https://gist.github.com/mpaccione/f834da643e1eef175c383a1c04448bbe

Here is some of the output of the dunst debug https://gist.github.com/mpaccione/dd015d04949ec08f218dd46103013f41

I have Xinerama set to 1 in my X11 configuration. I am running some nvidia-driver-450 (proprietary). Two screens on an HDMI and one on an adapter to some type of mini-hdmi port. GeForce GTX 970 GPU.

Thank you!

[fwsmit]

Here is the output of querying the extensions https://gist.github.com/mpaccione/f834da643e1eef175c383a1c04448bbe

To me it looks like the xrandr and xinemera extensions are not properly installed on your system. Could take a look if those are all installed?

Here is some of the output of the dunst debug https://gist.github.com/mpaccione/dd015d04949ec08f218dd46103013f41

I have Xinerama set to 1 in my X11 configuration. I am running some nvidia-driver-450 (proprietary). Two screens on an HDMI and one on an adapter to some type of mini-hdmi port. GeForce GTX 970 GPU.

You setup seems fine. I didn't know there was a X11 config. What config do you mean exactly?

[mpaccione]

Here's a screenshot of part of the xorg.conf which is the global conf file for X11 server found in /etc/X11.

You can see I have Xinerama enabled. I don't know how I would properly install xrandr or xinerama then. Would I need to fully reinstall X11 (Nvidia X Server)? I'm a bit hesitant because it took awhile to get my triple monitor xinerama setup working on Linux. There's no extensions section in this file.

I'm wondering if that is an issue at all because I can run systemctl --user run dunst.service just fine after startup and seems to run all day. Would these errors cause a problem for the systemd?

[fwsmit]

Here's a screenshot of part of the xorg.conf which is the global conf file for X11 server found in /etc/X11.

You can see I have Xinerama enabled. I don't know how I would properly install xrandr or xinerama then. Would I need to fully reinstall X11 (Nvidia X Server)? I'm a bit hesitant because it took awhile to get my triple monitor xinerama setup working on Linux. There's no extensions section in this file.

I'm wondering if that is an issue at all because I can run systemctl --user run dunst.service just fine after startup and seems to run all day. Would these errors cause a problem for the systemd?

You're right, they're not neccesary, but I thought they might signal a problem in your setup. You obviously have at least xinemera installed, because I don't think you could otherwise be using multiple monitors. To debug this further I would suggest starting dunst -verbosity debug >> ~/dunst.log to see what it's output is upon starting up. You could do the same thing if you must use systemd to start dunst by editing the service file and set the command to dunst -verbosity debug. For the systemd service you could also systemd-analyze critical-chain dunst to see in what order the services was started.

[mpaccione]

Okay so one thing I've noticed is that I cannot do:

systemctl start dunst.service

However adding the user flag works...Seems I got the Xinerama errors to go away :shrug: I think I poked around last week on it... it's been mad busy kinda forget lol.

Perhaps its just not referencing it correctly on load? Or maybe a syslink somewhere? This is my service file from usr/lib/systemd

Here was the systemmd output...

The verbosity logging didn't output much but maybe I need to add the flags to the on systemmd startup path

[fwsmit]

Okay so one thing I've noticed is that I cannot do:

systemctl start dunst.service

However adding the user flag works...

That's perfectly normal, I believe. Dunst is intended to run as a user, not as root. thus the systemd services is installed as a user service and not a system one (look at the directory of the service).

Seems I got the Xinerama errors to go away shrug I think I poked around last week on it... it's been mad busy kinda forget lol.

There must be something weird about your setup. Can't help you with the RANDR warning unfortunatly.

Does the systemd service start correctly now or does it still give the same error message?

Here was the systemd output...

I'm sorry it should have been systemd-analyze critical-chain dunst.service.

[mpaccione]

Okay thank you fwSmit this would appear to be working.

Upon rebooting and checking the --user flag it appears to work on load.

Here is the output of the systemd-analyze

I think this line

and fixing whatever the Xinerama issue was has unblocked me on this. God I wish i just remembered what that exact tweak was. Regardless thank you for your help. I doubt I would have worked with it enough to get it going if I was on my own. Figure theres enough media here to help the next person! :)

[fwsmit]

Nice that it's fixed. I just want to mention that you shouldn't need the Environment line. It's not best practice to hard code the DISPLAY variable and all modern distros should ship a file that looks like the following (wayland compositors will need a similar file, but specific to the compositor):

/etc/X11/xinit/xinitrc.d/50-systemd-user.sh

#!/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

This should import the DISPLAY variable into the user systemd environment.

[mpaccione]

Gotcha, yeah I think in the ticket I referenced earlier they mentioned a similar thing. Thank you for providing the code context.

I remember installing this:

sudo apt-get install -y x11-xserver-utils

Believe that fixed Xinerama reference and got it working!

[mpaccione]

@fwSmit Wow your not gonna believe this... it appears to not work.

I have been tweaking some stuff so maybe this new error is the actual blocker?... At this point it seems particularly tricky because sometimes its good and sometimes not.

MIT-MAGIC-COOKIE=1 Sounds tasty but what the heck lol!

[fwsmit]

Could you send the output of critical-chain again? It seems like the dunst service is started too early. Maybe even at the same time as the X server, which would explain why it sometimes works.

[fwsmit]

ping @mpaccione

[mpaccione]

Thanks for your patience @fwSmit ... Here is the output from the console after loading up.

[fwsmit]

@mpaccione Dunst starts after basic.target here. This should be graphical-session.target. Could you try using this systemd unit for dunst:

dunst.service

[Unit]
Description=Dunst notification daemon
Documentation=man:dunst(1)
PartOf=graphical-session.target
After=graphical-session.target

[Service]
Type=dbus
BusName=org.freedesktop.Notifications
ExecStart=/usr/bin/dunst
    
[Install]
WantedBy=graphical-session.target

I've added the After= and [Install] part.

[mpaccione]

This was the previous systemd

Okay here it is with the new systemd

This is the critical-chain I get. It looks like mount is new?

[fwsmit]

It seems like this is still the output of the old service. Could try to systemctl --user edit dunst.service?

[mpaccione]

Hey @fwSmit

Here is the updated results in using the systemctl --user edit dunst.service. I was unaware I could edit it that way so thank you. I had followed the "Loaded" path previously and then edited and reloaded the daemons.

However with your approach it appears that the override.conf gets loaded. This MIT-MAGIC-COOKIE appears to be back and I don't know where the rogue baker is.

[bynect]

did you solve this in the end?