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

Help
1

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?

2

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.

3

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?

4

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
5

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
6

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
7

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