dunst

dunst copied to clipboard

Issue description

I have this error coming up in my dmesg on every single boot. It is not new, it must be there since v1.5 (if not earlier) and the only way to make it go away is to completely uninstall dunst.

$ dmesg | grep dunst
[    7.821420] traps: dunst[517] trap int3 ip:7f5e6b10de92 sp:7fff4fc8ea70 error:0 in libglib-2.0.so.0.7400.2[7f5e6b0cf000+8c000]

Installation info

• Version: 1.8.1
• Install type: package (apt-get install dunst)
• Window manager / Desktop environment: Openbox

Dunstrc here

I can not create a minimal dunstrc for the issue, so here is my entire dunstrc file. It is basically the default one, with some changes in the font and colors and I created it fresh right after the upgrade to 1.8.1 (straight from 1.5.0). The old file was created around 2016 and I have kept it as a backup. https://paste.debian.net/hidden/edfe0eeb/

I got the upgrade to v1.9.0 today but the error is still there.

This might be a distro issue. It would be useful to provide a backtrace.

I have never done a backtrace before, but I will try it. Please be patient :)

---edit But before that, I have to find a way to disable it from startup so as to run it at will. It has a systemd service file in its package, but it is not started by systemd. So, is killing it enough to produce backtrace results?

If it always crashes you can do the following:

pkill dunst
gdb dunst -ex r -ex bt

Also, what distro are you using?

But I'm not even sure if a trap is a crash. If not, it's not as easy to generate a backtrace

It does not crash at all. It is just that weird message it pops on every in dmesg. I am on debian testing/unstable x64.

Ok here goes my first try with gdb.

Reading symbols from dunst...
(No debugging symbols found in dunst)
Starting program: /usr/bin/dunst 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6d786c0 (LWP 4003)]
[New Thread 0x7ffff65776c0 (LWP 4004)]
[New Thread 0x7ffff57ff6c0 (LWP 4005)]
[Thread 0x7ffff65776c0 (LWP 4004) exited]
[New Thread 0x7ffff65776c0 (LWP 4016)]
[New Thread 0x7ffff4ffe6c0 (LWP 4017)]
[New Thread 0x7fffe7fff6c0 (LWP 4021)]
[Thread 0x7fffe7fff6c0 (LWP 4021) exited]
[New Thread 0x7fffe7fff6c0 (LWP 4022)]
[New Thread 0x7fffe77fe6c0 (LWP 4023)]
[New Thread 0x7fffe7fff6c0 (LWP 4024)]
[Thread 0x7fffe7fff6c0 (LWP 4022) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 4025)]
[Thread 0x7fffe7fff6c0 (LWP 4024) exited]
[Thread 0x7fffe6ffd6c0 (LWP 4025) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 4026)]
[New Thread 0x7fffe7fff6c0 (LWP 4027)]
[Thread 0x7fffe77fe6c0 (LWP 4023) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 4028)]
[Thread 0x7fffe6ffd6c0 (LWP 4026) exited]
[New Thread 0x7fffe77fe6c0 (LWP 4029)]
[Thread 0x7fffe6ffd6c0 (LWP 4028) exited]
[Thread 0x7fffe7fff6c0 (LWP 4027) exited]
[Thread 0x7fffe77fe6c0 (LWP 4029) exited]
[Thread 0x7ffff65776c0 (LWP 4016) exited]

I sent a "notify-send something" to see if it works and it was working. After all that I pressed ctrl+c and then q to exit gdb. Please note that killing dunst and relauncing it did not produce the error in dmesg. In fact, nothing was written in dmesg.

There is nothing useful in this output. Does the issue even happen when running dunst from the command line? If not, you'll have to look at how exactly dunst is started and what is different about starting that way.

I thought so :( The issue seems to happen only on boot and not when running dunst again (after killing it). Sadly, I can not find how it is started on boot or login. It has a systemd service, but it is not active, it is not started from /etc/xdg/autostart/ (like wbar) and I do not start it manually via ~/config/openbox/autostart (like conky).

maybe dunst is started too soon? can you change the order of the processes?

How can I know when it is started? There is a dunst.service file, but it is not even enabled as it seems.

$ systemctl status dunst.service
Unit dunst.service could not be found.

How can I know when it is started? There is a dunst.service file, but it is not even enabled as it seems.

$ systemctl status dunst.service
Unit dunst.service could not be found.

wait. so you have the error in dmesg but systemd is not starting dunst?

You should find out who is starting it then. If dusnt is correclty configured as the default notification daemon it will start automatically when a notification is sent, so you can disable the start at boot thing entirely

It may be dbus, because it has some dbus related file as you can see here https://packages.debian.org/sid/amd64/dunst/filelist

As for dunst being the only notification daemon, it probably is because I have none of the remaining packages listed here that can provide A notification daemon https://packages.debian.org/sid/notification-daemon

It seems like some other user in the internet incurred in a sigtrap sent by debian libglib. https://stackoverflow.com/questions/61816297/what-is-int-3-really-supposed-to-do https://stackoverflow.com/questions/63340398/trap-int3-error-in-libglib-debian-eclipse https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935889

Now, I suspect you are using an x86 system, because it seems for those systems libglib uses traps instead of abort.

My hypothesis: during the boot process some program (maybe even dbus itself) is starting dunst too early, so dunst is erroring out in some unknown way that is causing an error in libglib. Or maybe libglib is corrupted/unilitialized.

I would say you can do a diskcheck, reinstall libglib competely and also dunst to the latest version. Then if the error is not solved, figure out where dunst is being started

Libglib has taken a couple of updates since then, like dunst which is now on 1.9.2. In fact, it is now on 2.78.4 and the only thing different in dmesg (excluding the memory addresses) is the name of the lib

$ dmesg | grep dunst
[   13.613972] traps: dunst[631] trap int3 ip:7f559fcb1c79 sp:7ffe2a297d20 error:0 in libglib-2.0.so.0.7800.4[7f559fc6d000+99000]

And it seems that libglib is no ordinary library, because dozens of packages depend on it on my (simplistic) setup. All 3 of my browsers, gtk2/3 apps and libraries, qt5/6 apps and libraries and even apps with no ui, like mpv or mplayer, depend on it. And yet, no other app pops anything similar in dmesg so as to indicate it is corrupted.

As for quering dbus for dunst, it gives a similar error to systemd about dunst's status

$ busctl status dunst.service
Failed to get credentials: No such device or address
$ sudo busctl status dunst.service
Failed to get credentials: No such device or address

Libglib has taken a couple of updates since then, like dunst which is now on 1.9.2. In fact, it is now on 2.78.4 and the only thing different in dmesg (excluding the memory addresses) is the name of the lib

$ dmesg | grep dunst
[   13.613972] traps: dunst[631] trap int3 ip:7f559fcb1c79 sp:7ffe2a297d20 error:0 in libglib-2.0.so.0.7800.4[7f559fc6d000+99000]

And it seems that libglib is no ordinary library, because dozens of packages depend on it on my (simplistic) setup. All 3 of my browsers, gtk2/3 apps and libraries, qt5/6 apps and libraries and even apps with no ui, like mpv or mplayer, depend on it. And yet, no other app pops anything similar in dmesg so as to indicate it is corrupted.

As for quering dbus for dunst, it gives a similar error to systemd about dunst's status

$ busctl status dunst.service
Failed to get credentials: No such device or address
$ sudo busctl status dunst.service
Failed to get credentials: No such device or address

This is really weird. Is my assumption of 32 bit libglib right?

I can think of two thing at the moment: Either the version of dunst is installed incorrectly (which is weird considering debian) or again dunst is started in an improper way during boot.

I would say, try to remove the debian version and compile and install from git and see if still persist with manual installation. If that's the case we have to find out who and when starts dunst

Also, could you send the surrounding context of the dmesg error?

Also libglib is like an extra standard library for c made by gtk, so it's normal that many program depend on it. Verifying the installation wouldn't hurt though

It's 64 bit. Call me cocky, but there is no 32bit lib on my system.

$ file /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.4
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=494f1601eab85c409c692018c500f17028ec31c2, stripped

And here is a full dmesg, although there is only one line for dunst https://paste.debian.net/hidden/cb01eaf9/

As for compiling it on my own... yea this is not a task for me, sorry :(

It's 64 bit. Call me cocky, but there is no 32bit lib on my system.

$ file /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.4
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=494f1601eab85c409c692018c500f17028ec31c2, stripped

And here is a full dmesg, although there is only one line for dunst https://paste.debian.net/hidden/cb01eaf9/

As for compiling it on my own... yea this is not a task for me, sorry :(

I see. Online I found that the trap signal is used instead of abort on 32 bit, but on x64 am not too sure.

To compile yourself is fairly simple, you have just to download the repository (either git clone or the zip) and run make install

I know that fairly simple way. Before that "make install" part, I must also have all build dependencies available or it won't build, and that is annoying for me.
Anyway, I will look for a way to check how dbus or anything loads it at the start. If I don't find anything helpful, I will close the issue and let dunst be, as long as it still works.

Looking back to it, maybe dunst was being started before the wm/de was properly initialized. #1174 presents a segfault when dunst is started before the wm. Maybe it is related?

In general dunst should be launched only after dbus and a xorg session. So maybe you have to change the order of process or disable dunst being started during boot?

How can I do that? Because a) we are in the systemd era and such "this starts after that" incidents are now taken care by systemd with the "After=" parameter, e.g. transmission-daemon starts after networking ONLY because of this bit After=network.target b) dunst does not start as a service here, as I mentioned above

Dbus is started as a service and xorg is started by lightdm, which in turn is started as a service too.

How can I do that? Because a) we are in the systemd era and such "this starts after that" incidents are now taken care by systemd with the "After=" parameter, e.g. transmission-daemon starts after networking ONLY because of this bit After=network.target b) dunst does not start as a service here, as I mentioned above

Dbus is started as a service and xorg is started by lightdm, which in turn is started as a service too.

Make a dunst service and make it depend on dbus/xorg. We have a systemd file already written in the repo. You can try using it.

However if it persist you have to find who starts dunst

I think I will do the second option first. So, assuming dbus starts it, how can I tell when it starts or stop it temporarily? Stopping dbus completely is out of the question, as it is a core component of the entire os and many other services and apps will fail.

I think I will do the second option first. So, assuming dbus starts it, how can I tell when it starts or stop it temporarily? Stopping dbus completely is out of the question, as it is a core component of the entire os and many other services and apps will fail.

I am not sure that dbus is the one starting dunst in the first place. To help you more you should get a core dump from dunst (for example with systemd coredump)

I think trying the systemd service file is fairly easy and non breaking, could you try it just in case?

I made a major discovery! Dunst IS started as a systemd service, but as a USER service, so I assume this is what you want.

$ systemctl status dunst --user
● dunst.service - Dunst notification daemon
     Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-03-03 17:11:58 EET; 1h 44min ago
       Docs: man:dunst(1)
   Main PID: 1590 (dunst)
      Tasks: 4 (limit: 4665)
     Memory: 3.4M (peak: 3.9M)
        CPU: 1.126s
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/dunst.service
             └─1590 /usr/bin/dunst

Mar 03 17:11:58 machine systemd[612]: Starting dunst.service - Dunst notification daemon...
Mar 03 17:11:58 machine systemd[612]: Started dunst.service - Dunst notification daemon.

good to know! Does systemd allow you to see a stack trace / core dump when the crash occurs? Also is the service properly configured to start after the wm/de?

Do these help?

$ cat /usr/lib/systemd/user/dunst.service
[Unit]
Description=Dunst notification daemon
Documentation=man:dunst(1)
PartOf=graphical-session.target

[Service]
Type=dbus
BusName=org.freedesktop.Notifications
ExecStart=/usr/bin/dunst

$ cat /usr/share/dbus-1/services/org.knopwob.dunst.service
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/bin/dunst
SystemdService=dunst.service

I am still trying to figure out how to ask systemd for a coredump.

The systemd service file is the same in the repo so it should work.

am still trying to figure out how to ask systemd for a coredump.

https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html

If we can pinpoint the crash to a precise stacktrace it would be ideal for debugging 👍🏻

Another user resolved a similar issue here: https://github.com/dunst-project/dunst/issues/1340#issuecomment-2066733836