Add dunst service

[RocketPuppy]

Motivation for this change

Picking up #58209 and adding examples, defaults, and rebasing on master to fix merge conflicts.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[xaverdh]

Thanks for picking this up, I tested it on my system and looks good so far :)

[RocketPuppy]

There's something here that I'm not quite happy with when modifying the dunst configuration, and I think it has to do with it being a user service but I'm not too familiar with NixOS's management of that. I nixos-rebuild switch, and the systemd unit shows this line: Feb 06 14:07:45 dwtnixos systemd[1816]: dunst.service: Current command vanished from the unit file, execution of the command list won't be resumed.. I assume this is because NixOS is doing a daemon-reload on the user units, and the command changed because the config file changed. At this point, the new config is not loaded, but restarting the service will load it. However, testing this using notify-send (or any notification that I'm testing) seems to always start a new dunst process that does not use the right config.

[RocketPuppy]

Looking into the above some more it seems like the dunst process started by the systemd service isn't connected to the same dbus. Echoing DBUS_SESSION_BUS_ADDRESS in the service gives /run/user/1000/bus, which looks to be from nixos/modules/services/x11/display-managers/default.nix importing that variable. In my terminal however, the value of DBUS_SESSION_BUS_ADDRESS is different, unix:abstract=/tmp/dbus-YmXEExbzhH,guid=3303447c070ed8b1a512da0c601eef32. And a debugging command from the Dunst FAQ, shows no notifications service registered:

 $ gdbus call --session --dest org.freedesktop.DBus --object-path /org/freedesktop/Dbus --method org.freedesktop.DBus.ListNames
(['org.freedesktop.DBus', ':1.30', ':1.3', ':1.2'],)

until I start dunst in a terminal:

$ gdbus call --session --dest org.freedesktop.DBus --object-path /org/freedesktop/Dbus --method org.freedesktop.DBus.ListNames
(['org.freedesktop.DBus', 'org.freedesktop.Notifications', ':1.3', ':1.31', ':1.32', ':1.2'],)

which explains why it would autostart dunst when a notification was sent, and is indicative to me that indeed the systemd dunst is not connecting to the right bus.

[rnhmjoj]

I assume this is because NixOS is doing a daemon-reload on the user units, and the command changed because the config file changed.

Correct, nixos-rebuild switch will do a daemon-reload but won't restart user servics. I'm not sure why, but it has been documented in the manual[1].

However, testing this using `notify-send` (or any notification that I'm testing) seems to always start a new dunst process that does not use the right config.

That's most likely due to dbus autostarting dunst, skipping the unit file. I'm not familiar with dbus so I don't know how any of this work, but you could workaround it buy placing the configuration file in /etc/dunst/dunstrc, instead of overriding the `ExecStart`. [1]: https://nixos.org/manual/nixos/unstable/index.html#sect-nixos-systemd-nixos

[RocketPuppy]

I'm not familiar with dbus so I don't know how any of this work, but you could workaround it buy placing the configuration file in /etc/dunst/dunstrc, instead of overriding the ExecStart.

I may have to do this if I can't pinpoint the problem soon. Right now I've found that I have three dbus-daemon processes running. Two "user" busses and one system bus. My hunch is there should only be one user bus. Here's a slice of my systemd cgroup tree:

           ├─user.slice
           │ └─user-1000.slice
           │   ├─[email protected]
           │   │ ├─dunst.service
           │   │ │ └─1876 /nix/store/yk40zknzxny71hcqyznjq48wyqw7pdjd-dunst-1.4.1/bin/dunst -config /nix/store/18nkzkwrvskzwz5vhijgzvhgxfrqhbdi-dunstrc -verbosity debug
           │   │ ├─dbus.service
           │   │ │ └─1879 /nix/store/d8ps9nn4fy4byhglqg27svsacg88wiyg-dbus-1.12.16/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │   └─session-1.scope
           │     ├─1845 /run/current-system/sw/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session

Process 1845 is the one that's receiving notifications it seems. At the very least I see logs for the notifications I tested sending. Process 1879 doesn't seem to be logging anywhere, but I imagine that's the bus that dunst (process 1876) is connected to. My question now is: Why is dbus-daemon being launched under my session scope when there is a dbus service for it?

Because it may be relevant now: NixOS version 20.03.3324.929768261a3 (Markhor). I'll try upgrading to 20.09 and see if that fixes the issue.

[RocketPuppy]

Because it may be relevant now: NixOS version 20.03.3324.929768261a3 (Markhor). I'll try upgrading to 20.09 and see if that fixes the issue.

Upgrading to 20.09 seems to have fixed my issue. I saw a few issues related to dbus that were closed (I can't find them again now). Perhaps one of those fixed the duplicate daemons.

I'm going to experiment with the daemon-reload now and see if I can get the dunst service to reload with the new config.

[RocketPuppy]

It doesn't look like dunst provides any way to reload the configuration of a running process, and even if it did systemd daemon-reload doesn't seem to trigger the ExecReload line. So for now I'll guess I'll just live with the status quo that user services aren't restarted when nixos-rebuild is run. I'm satisfied with this as is.

[xaverdh]

For reference here is the dunst issue for implementing config reload in the future: dunst-project/dunst#719

[stale]

I marked this as stale due to inactivity. → More info

[abathur]

@RocketPuppy Are you still interested in landing this?

[RocketPuppy]

@abathur No, apologies. I don't have the time to wrap this up right now.

[abathur]

No worries :)

Just doing cleanup so that others don't try to pick it up. I'm going to tentatively close this, but I'm happy to reopen if you ping me.