Display-manager.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing

I’m on nixos unstable and running hyprland with greetd. Everything works fine but on every boot i get an entry in journalctl like this:

-- Boot 227af101764b4d36a19ac362290f6b44 --
Feb 21 12:48:28 nixos systemd[1]: display-manager.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.

Why is this occuring and is there a way to correct it?

Additional question regarding the journal:

I often (not always) get Feb 21 09:20:25 nixos kernel: watchdog: watchdog0: watchdog did not stop! on shutdown. What’s causing this and can this be avoided?

I’d wager you created a nearly empty display-manager.service somewhere accidentally. What file does systemctl status display-manager.service refer to, and what nix store path is it in?

A lot of things can cause this, it’s usually misbehaving hardware/firmware, but I’ve seen VMs still running on shutdown trigger this message too.

journalctl --boot -1 might give some insights. Also check GitHub - NixOS/nixos-hardware: A collection of NixOS modules covering hardware quirks. for your system.

Failing that, search the web for your hardware and that error, arch forum posts and stackoverflow might have some answers.

I’m sorry, how can i see which file and nix store path it refers to?

If i run it in the terminal i get:

systemctl status display-manager.service                                                                                                                           17:58
○ display-manager.service
     Loaded: bad-setting (Reason: Unit display-manager.service has a bad unit file setting.)
     Active: inactive (dead)

Feb 22 12:23:47 nixos systemd[1]: display-manager.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.
Feb 22 12:23:48 nixos systemd[1]: display-manager.service: Cannot add dependency job, ignoring: Unit display-manager.service has a bad unit file setting.

I never (knowingly) added systemd units directly via the terminal and only did so via my configuration.nix. There i have no display-manager.service defined.

I’ve set programs.hyprland.enable = true;. Is this meant to take care of the display-manager.service or is this unrelated?

I do not think greetd even uses display-manager.service – I do not see it mentioned anywhere in https://github.com/NixOS/nixpkgs/blob/3e4736c4186b32bf42c7ed80fc32d676caf4a6f4/nixos/modules/services/display-managers/greetd.nix#L63 or in the project tree.

I actually got the same error when I accidentally removed services.xserver.enable but still had services.xserver.displayManager.gdm.enable = true;. Are you sure you do not have some other display manager enabled?

1 Like

Hm, normally it shows in the systemctl status output:

nvidia-hibernate.service - NVIDIA system hibernate actions
     Loaded: loaded (/etc/systemd/system/nvidia-hibernate.service; enabled; preset: enabled)
     Active: inactive (dead)

Guess not if it fails to load, though. I was hoping it’d tell us what exactly you have enabled that activates that unit, it’s supposed to be masked if you don’t use a desktop manager.

1 Like

One way this can happen is by trying to add settings to it when it doesn’t otherwise exist, or trying to add settings to something that comes from a templated base - but you override the template by creating a specific service instance.

This may not directly be the issue here (especially the template@ variant).

The way to deal with it, either for templates or in the case where you want to add settings to a service that may or may not exist, is to ask nix to deploy those settings using a dropin file, like so:

  systemd.services."systemd-nspawn@instancename" = {
    wantedBy = [ "multi-user.target" ];
    overrideStrategy = "asDropin";

In your case, if you can find the settings, you might just want to delete them.

Look in /etc/systemd/system/display-manager.service, or for other files under systemd paths with display-manager as the name. The contents of what is there might give you a clue where it’s coming from.

1 Like

Your combined answers led me to the solution: i had set systemd.services.display-manager.restartIfChanged = false and this was causing the error. I didn’t realize that this option would create a stub systemd unit if one wasn’t present already.

Thank you all!

1 Like