"Hyprland was started without start-hyprland..." error on startup when using NixOs and withUWSM

[rickyelopez]

Hello!

I've started getting this error on startup since updating the hyprland flake to rev 0467be86b18cfc324fab04afbd40fe9ef80f7fa9. Not sure that that's the rev that introduced it, as I don't update to every rev.

I think this makes sense since uwsm in nixos is configured to run the Hyprland binary directly, but is this intentional? I've tried locally patching my nix config to run start-hyprland from UWSM instead (with programs.uwsm.waylandCompositors.hyprland.binPath = lib.mkForce "${hyprlandPackage}/bin/start-hyprland";), but then I get a warning about XDG_CURRENT_DESKTOP being managed externally. I haven't noticed any issues despite this warning (yet, at least). Is this the correct solution? Or should UWSM continue to run Hyprland directly, and then maybe a Hyprland gets a patch to suppress this error in this case?

[michaelbrusegard]

I notice the same 👍🏾

[Gako358]

Have the same, I have :
programs.uwsm.waylandCompositors.hyprland.binPath = lib.mkForce "/run/current-system/sw/bin/start-hyprland";

and in greetd i have: command = "${lib.getExe config.programs.uwsm.package} start -e -D Hyprland hyprland-uwsm.desktop";

Got same error, had to revert to Hyprland 0.52.0 built from branch unknown at commit f11cf6f1de708b6b3811788e8ff7984ff05a9546

[zevisert]

A search for "start-hyprland" site:hypr.land only returns one result right now: https://wiki.hypr.land/Getting-Started/Master-Tutorial/#launching-hyprland. I also have started seeing this, but without any adverse affects yet as far as I can tell.

I am also on NixOS running hyprland via flake from the development branch, I have the following nix config relating to hyprland:

{
  inputs, config, lib, pkgs,
  ...
}: {
  inherit (pkgs.stdenv.hostPlatform) system;

  imports = [ inputs.hyprland.nixosModules.default ];

  nix.settings = {
    substituters = ["https://hyprland.cachix.org"];
    trusted-substituters = ["https://hyprland.cachix.org"];
    trusted-public-keys = ["hyprland.cachix.org-1:a7pgxzMz7+chwVL3/pzj6jIBMioiJM7ypFP8PwtkuGc="];
  };

  programs = {
    hyprland = let
      hyprpkgs = inputs.hyprland.packages."${system}"
    in {
      enable = true;
      withUWSM = true;
      package = hyprpkgs.hyprland;
      portalPackage = hyprpkgs.xdg-desktop-portal-hyprland;
      settings = { ... };
    };
  };
}

[mononomori]

I am getting the same error.

[fufexan]

I'm currently working on this issue. The simplest way to get it to work is to set withUWSM = false, not set programs.uwsm.enable = true, but instead set

  environment.systemPackages = [ pkgs.uwsm ];
  systemd.packages = [ pkgs.uwsm ];
  environment.pathsToLink = [ "/share/uwsm" ];

Also don't forget to use dbus-broker if you aren't doing it explicitly already.

To use the hyprland-provided hyprland-uwsm.desktop, the derivation's cmakeFlags have to be modified to
No longer needed, this was merged.

-        "NO_UWSM" = true;
+        "NO_UWSM" = !withSystemd;

If you use greetd, the above is not needed, you only have to use uwsm start -eD Hyprland hyprland.desktop.

Related Vladimir-csp/uwsm#186

[fufexan]

Alternatively, @Gako358's solution should work.

[hmanhng]

i change hyprland-uwsm.desktop to hyprland.desktop, and it say Could not find hyprland.desktop
what is issue?
need change withUWSM = false too ?

[fufexan]

need change withUWSM = false too ?

Yes, as described above.

[G0d-0f-D34th]

if i dont change anything now, and let it be then will it automatically be resolved a month later?

[Vladimir-csp]

a warning about XDG_CURRENT_DESKTOP being managed externally

Why is such warning even needed? What if someone makes a session using Hyprland with their own desktop names, either including Hyprland or not?

[Faeranne]

There's a new config option that disables the warning. setting wayland.windowManager.hyprland.settings.misc.disable_watchdog_warning = true; disables the warning.

[michaelbrusegard]

Is it a safe approach to use this or do we want to change to use the start hyprland?

[Vladimir-csp]

I'd recommend feeding hyprland.desktop to uwsm. Assuming it will have start-hyprland with all the proper Nix paths included everywhere.

Basic scheme: if you run uwsm explicitly, use equivalent of uwsm start hyprland.desktop, if you start via DM, select hyprland-uwsm.desktop which itself should run uwsm start hyprland.desktop.

How the watchdog will behave with systemd: I don't know yet, but nothing points to trouble if it handles and transmits signals to Hyprland itself. The only potential problem is notification socket interaction, but it is minor.

The next uwsm release will not autoadd basename of compositor's executable to desktop names if higher priority data came before it (taken directly form entry's DesktopNames or came from XDG_CURRENT_DESKTOP in login context set by a DM). So if the entry says Hyprland, it will be that.

[michaelbrusegard]

Thank you for the answer @Vladimir-csp
I recently switched to DankMaterialShell, so I think it is responsible for launching hyprland in my current configuration. In addition I have a separate hyprland instance coming from greetd. For reference: https://github.com/michaelbrusegard/dotfiles/blob/main/modules/wayland/hyprland.nix and https://github.com/michaelbrusegard/dotfiles/blob/main/hosts/desktop/programs.nix

I am a little unsure about uwsm since I have not dabbled in managing multiple different wayland sessions. I only have a single Hyprland session for my user which is all I really need :).

[Faeranne]

Is it a safe approach to use this or do we want to change to use the start hyprland?

shrug I mean, it's just as safe as before the error, since before the watchdog wasn't being setup either. I assume setting this option is equivalent to saying "I take responsibility for this breaking". I had some issues with signals not getting passed correctly to hyprland and stuff wasn't closing correctly when exiting hyprland with uswm. Given nix provides ways to rollback, I'm personally not worries about having the watchdog, since I can still get into my system if something does goes wrong.

[logrusx]

For whoever is using Hyprland as the compositor for SDDM it's enough to change the CompositorCommand to start-hyprland in sddm's configuration file in /etc/sddm.conf.d/ and the warning goes away. From then on SDDM should start properly whatever session you've chosen. At least it looks like that for me.

[diesel701]

The only thing to pay attention is if you have any flags or arguments. You need to add -- after start-hyprland.
From the wiki:

You can use some launch flags by doing start-hyprland -- -h, these include setting the config path, ignoring a check for the above, etc.

[Inbydev]

the same error happens to me when I try launching it on Arch with UWSM, downgrading to hyprland 0.52.2-3 fixed the problem for me for now

[logrusx]

#12661 (reply in thread)

[sweenu]

I use hyprland's own flake and for some reason, uswm wouldn't find hyprland.desktop. So here's my working solution for those who need it (I launch with fish):

    programs.fish.interactiveShellInit = lib.mkBefore ''
      if uwsm check may-start -q
          exec uwsm start ${config.programs.hyprland.package}/share/wayland-sessions/hyprland.desktop
      end
    '';

[fufexan]

It tends not to find it if you don't have any display manager set. You can manually set

 environment.sessionVariables.XDG_DATA_DIRS = lib.mkIf (config.services.dispayManager.sessionPackages != [ ]) [ 
   "${config.services.displayManager.sessionData.desktops}/share" 
 ];

[Iamvismorf]

I get attribute desktops does not exist error. Enabling displayManager solves the issue but then the screen just hangs at boot at target reached graphical interface. Can someone help?

[swimsloth]

I was going to open a separate discussion because I had an issue with uwsm and screen sharing specifically due to this warning. But since this is already open I will share my workaround for removing the warning and getting the desktop portal to function properly.

I had an issue with screen sharing not working while launching with uwsm. I was trying to screenshare with discord but the display picker did not show up.

My first course of action as to make sure that XDPH was installed, but since I am using the nixos module that is on by default. I then checked that qtwayland was installed but that didn't change the issue. Then I saw in the wiki that the XDG environment variables are important for the desktop portal to function properly https://wiki.hypr.land/Configuring/Environment-variables/#xdg-specifications.

When I checked XDG_SESSION_DESKTOP it seems that uwsm sets it to start-hyprland instead of Hyprland. So I followed the instructions at the top of the https://wiki.hypr.land/Configuring/Environment-variables/ page, and set export XDG_CURRENT_DESKTOP=Hyprland in the ~/.config/uwsm/env file and that fixed the issue.

[Vladimir-csp]

it seems that uwsm sets it to start-hyprland instead of Hyprland.

It sets whatever it can. If just an executable is given and no info was provided, it falls back to the basename of the executable given. Launch hyprland.desktop instead, it has the correct DesktopNames, so XDG_CURRENT_DESKTOP and derivatives will be set correctly without any tweaks.

[lohaniprateek]

Is this because of the latest update or something else, like if I told you my scenario, I was switching to greeted + tuigreeet from SDDM, and the very first time I logged in saw this Warning. And haven't tested screen sharing and other functions yet, to see if they're working or not. As in this discussion, most people are from the Nix community, and being a Noob, will it also be the same for Arch, or might there also be some differences?

[nathansizemore]

I am also on arch, greetd + tuigreet, just started receiving the same error after updating today:

[terminal]
# The VT to run the greeter on. Can be "next", "current" or a number
# designating the VT.
vt = 2

# The default session, also known as the greeter.
[default_session]

# `agreety` is the bundled agetty/login-lookalike. You can replace `/bin/sh`
# with whatever you want started, such as `sway`.
# command = "agreety --cmd /bin/sh"
command = "tuigreet --time --remember --cmd Hyprland"

# The user to run the command as. The privileges this user must have depends
# on the greeter. A graphical greeter may for example require the user to be
# in the `video` group.
user = "greeter"

[nathansizemore]

Changing to this line fixed it for me:

command = "tuigreet --time --remember --cmd /usr/bin/start-hyprland"

[lohaniprateek]

Worked well for me too.
Thanks!!

[GedeSaika]

@nathansizemore thanks friend this worked for me i deleted my code the problematic part and replaced it with your suggestion

[J040Pablo]

In my case this wasn’t a Hyprland bug or anything NixOS-specific.
I’m on Arch Linux using greetd + tuigreet, and the warning appeared because the display manager was starting the Hyprland binary directly instead of using the recommended start-hyprland script.

Hyprland now shows this warning whenever it’s not launched via start-hyprland, since that script sets up important environment variables (XDG, portals, Electron apps, screen sharing, etc.).

How I fixed it (greetd + tuigreet)

I just changed the command in greetd’s config:

Before:

command = "tuigreet --cmd Hyprland --user-menu"

After:

command = "tuigreet --cmd start-hyprland --user-menu"

File:

/etc/greetd/config.toml

Then restart greetd or reboot:

sudo systemctl restart greetd
# or reboot

Result:

• The warning is gone
• Hyprland starts the intended way
• XDG / portals / screen sharing work as expected

So the warning is valid, and the fix is simply making sure your display manager (in my case, greetd/tuigreet) launches start-hyprland instead of Hyprland directly.

[mononomori]

Are you using UWSM?

[hesprs]

I also encountered this problem after I updated Hyprland yesterday. I believe this is mostly not NixOS or UWSM specific. The issue arises since Hyprland changes its inner working.

The fix is simple and works for all distros (e.g. with greetd + tuigreet):

# Common Distros (in greetd's config)
command = "tuigreet --cmd start-hyprland --user-menu"

# NixOS
services.greetd.settings.default_session.command = "${pkgs.tuigreet}/bin/tuigreet --cmd start-hyprland";

Specially, for those using UWSM (I don't use UWSM, but I guess the situation is):

You cannot configure greetd since it is managed by UWSM. Contacting its maintainer is the best solution.

[n3rsti]

I don't have the exact same issue, but for me after the update the uwsm just doesn't work? There is no uwsm process and session starts without graphical-session.target. I was trying to debug it, but I am not sure how. Maybe someone else had the same issue

[n3rsti]

Also this output might help:

 nixos (main) ✗ cat /nix/store/*-desktops/share/wayland-sessions/*.desktop
[Desktop Entry]
Name=Hyprland
Comment=An intelligent dynamic tiling Wayland compositor
Exec=Hyprland
Type=Application
DesktopNames=Hyprland
Keywords=tiling;wayland;compositor;

[Desktop Entry]
Name=Hyprland
Comment=An intelligent dynamic tiling Wayland compositor
Exec=//nix/store/4b7y5q10x5n3qc9m4d9mgnnmnh2gm2hy-hyprland-0.53.1/bin/start-hyprland
Type=Application
DesktopNames=Hyprland
Keywords=tiling;wayland;compositor;

[Desktop Entry]
Name=Hyprland (uwsm-managed)
Comment=An intelligent dynamic tiling Wayland compositor
Exec=uwsm start -e -D Hyprland hyprland.desktop
TryExec=uwsm
DesktopNames=Hyprland
Type=Application

[Desktop Entry]
Name=Hyprland (UWSM)
Comment=Hyprland compositor managed by UWSM
Exec=/nix/store/x6dq19n8psm7dncc9azazr7qk7dymkw1-uwsm-0.24.3/bin/uwsm start -F -- /run/current-system/sw/bin/Hyprland
Type=Application

[Desktop Entry]
Name=Hyprland (UWSM)
Comment=Hyprland compositor managed by UWSM
Exec=/nix/store/1lmnzl03ic36711npgyfcqjc0m70ppj1-uwsm-0.25.3/bin/uwsm start -F -- /run/current-system/sw/bin/Hyprland
Type=Application

It looks like there is no new uwsm one?
I am using uwsm 0.26.0 after update and it should run start-hyprland if i understand correctly

[Vladimir-csp]

Basic Exec for a DM-launched entry is uwsm start -- hyprland.desktop, so in Nix context it would be something like /path/to/uwsm start -- /path/to/hyprland.desktop or /path/to/uwsm start -F -- hyprland.desktop depending what is discoverable by GDM in Nix. If this is not the case, I would suggest reporting a bug to Nix.

[zeorin]

NixOS commit NixOS/nixpkgs@9128dd3 broke the withUWSM option.

[zeorin]

Workaround:

{
  services.displayManager.sessionPackages = [
    (pkgs.writeTextFile {
      name = "hyprland-uwsm-fixed";
      text = ''
        [Desktop Entry]
        Name=Hyprland (UWSM)
        Comment=Hyprland compositor managed by UWSM
        Exec=${lib.getExe config.programs.uwsm.package} start -F -- /run/current-system/sw/bin/start-hyprland
        Type=Application
        DesktopNames=Hyprland
        Keywords=tiling;wayland;compositor;
      '';
      destination = "/share/wayland-sessions/hyprland-uwsm-fixed.desktop";
      derivationArgs = {
        passthru.providedSessions = [ "hyprland-uwsm-fixed" ];
      };
    })
  ];
}

[n3rsti]

Thanks!

[Zebra2711]

I use ly and have the same warning when running without uswm. We have /bin/Hyprland and the desktop file /usr/share/wayland-sessions/hyprland.desktop.
The login manager searches the Name field inside the .desktop file or the value of the DesktopNames field.

[Desktop Entry]
Name=Hyprland
Comment=An intelligent dynamic tiling Wayland compositor
Exec=/usr/bin/start-hyprland
Type=Application
DesktopNames=Hyprland
Keywords=tiling;wayland;compositor;

So it tries to run the hyprland.desktop using Hyprland (Name field), but the system has /bin/Hyprland, so it ends up running Hyprland(/bin/Hyprland) instead of the desktop file.

The workaround for ly is to change
Name=Hyprland -> Name=Hyprland0

[DartMitai]

I have Arch without any uwsm my config run but I also get this pop-up banner, how do I remove it?

# Start X at login
if status is-login
    if test -z "$DISPLAY" -a "$XDG_VTNR" = 1
        exec Hyprland
    end
end

[fxzzi]

exec Hyprland -> exec start-hyprland

or leave exec the same and add misc:disable_watchdog_warning = 1 to config