No notifications showing up after logging out and logging in.

[fwsmit]

Reproduction steps

• Log into sway (maybe it works in other environments as well)
• Start dunst. For me it's started by sway
• Notifications are working now
• Log out. Make sure dunst is still running
• Log back in
• No notifications are showing up, but dunst still receives them (as shown by logging dunst's output to a file)

I suspect this has something to do with wayland objects changing from one session to the other.

Installation info

• Version: v1.6.1-13-g3acffdb
• Install type: AUR
• Distro and version: Arch Linux
• WM: Sway (Wayland)

[bebehei]

How do you logout of your session while continuing to run sway?

Do you lock the screen or do you logout and login (stop and start a new sway instance)?

[fwsmit]

No I do exit sway and it stops running, but somehow Dunst still keeps running, even though it is started by sway. I'm not sure if that's a sway bug in itself.

[fwsmit]

My first theory was that the environment variables changed and that it is the reason why the old dunst doesn't work anymore, but that theory falls apart when you see Dunst still receives notifications from dbus

[bebehei]

Well, this might be an interesting point in overall combination with the current startup problems of the systemd unit.

If a DBus client accesses org.freedesktop.Notifications, DBus will start the systemd user unit, which will in turn then provide the org.freedesktop.Notifications service.

If we fix the systemd unit properly to bind dunst to the graphical session correctly, we might have fixed this smoothly and dunst stops, when the graphics server (may it be Xorg or wayland) stops. I tested some builds yesterday, but without any success yet.

(Disclaimer: Since moving to sway, I've got a workspace service, where some important not yet integrated services are started. Dunst ist now the last one. I've got a heavy interest in fixing the systemd unit properly).

[fwsmit]

Well, this might be an interesting point in overall combination with the current startup problems of the systemd unit.

Yeah there was an issue about that, although I couldn't confirm the bug.

If a DBus client accesses org.freedesktop.Notifications, DBus will start the systemd user unit, which will in turn then provide the org.freedesktop.Notifications service.

If we fix the systemd unit properly to bind dunst to the graphical session correctly, we might have fixed this smoothly and dunst stops, when the graphics server (may it be Xorg or wayland) stops. I tested some builds yesterday, but without any success yet.

PartOf=graphical-session.target should actually already to that according to the documentation:

  PartOf=
      Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a
      one-way dependency — changes to this unit do not affect the listed units.

      When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service.  ConsistsOf= dependency cannot be specified directly.

[fwsmit]

Note that fixing the systemd unit is only a workaround. This issue is about starting dunst with sway and not using dbus/systemd to start it. I haven't tested what happens when I use the systemd unit.

[fwsmit]

It seems most reasonable to me to just make sure dunst exits upon logging out. I think what could be messing up the drawing after logging out is that there is a different sway instance, but dunst still has state from the other instance (for example surfaces that it got).
Looking on the sway wiki, there seem to be two solutions:

• The systemd way (unsupported). Make services for every process you want to stop on sway exit: https://github.com/swaywm/sway/wiki/Systemd-integration
• The non-systemd way. Still means you have to make a configuration for every process you want to stop: https://github.com/swaywm/sway/wiki/Startup-(process-manager)-Integration

[poperigby]

So, is this bug fixed or should we fix it ourselves with one of those options?

[fwsmit]

You should try one of the two solutions mentioned in my last comment. I haven't tried them yet, but let me know if it works

[fwsmit]

Turns out, this can be fixed by dunst. Wayland clients are able to detect when the compositor stops through the wl_display. I'm working on a fix

[fwsmit]

I fixed this issue in #961. Since this messes with the event loop, I would like to test it pretty well. @bebehei or @lumbo7332, would you mind checking if it works for you?

[fwsmit]

Well, this might be an interesting point in overall combination with the current startup problems of the systemd unit.

If a DBus client accesses org.freedesktop.Notifications, DBus will start the systemd user unit, which will in turn then provide the org.freedesktop.Notifications service.

If we fix the systemd unit properly to bind dunst to the graphical session correctly, we might have fixed this smoothly and dunst stops, when the graphics server (may it be Xorg or wayland) stops. I tested some builds yesterday, but without any success yet.

(Disclaimer: Since moving to sway, I've got a workspace service, where some important not yet integrated services are started. Dunst ist now the last one. I've got a heavy interest in fixing the systemd unit properly).

@bebehei I've asked the sway maintainer about this and there seems to be no support for any kind of session management. If you want systemd units to work with graphical-session.target, you have got to do that yourselves. So make a systemd unit out of sway or start some sort of session unit from your sway config. But anyways, that's not needed for dunst anymore, since with the above linked PR it should automatically exit when you exit sway.

[fwsmit]

The fix has been merged