bug: Kanshi does not restart with Sway

[cyntheticfox]

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

Sway can restart without the systemd kanshi.service unit restarting, resulting in configuration not being applied correctly after Sway reload, as Kanshi doesn't get notified on reload. In fact, the Kanshi nixpkgs default.nix doesn't even include the optional libvarlink dependency, so its IPC hooks won't work anyways. Only way might be to add a conditional append to the Sway (or other Wayland WM) config's OnChange to restart the service with systemctl, since Sway isn't run as a Systemd service anyways.

I've currently fixed it by adding an activation entry as a workaround, but that's hardly a good fix imo.

Maintainer CC

@nurelin

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.16.14, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - channels(root): `"nixos"`
 - channels(david): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[nurelin]

Yeah, that is not ideal. I am not sure what should be done.

Concerning kanshictl, libvarlink is not part of the derivation because the ipc protocol has been added in an unreleased version of kanshi. I was able to build it using:

  services.kanshi = {
    enable = true;
    package = (pkgs.kanshi.overrideAttrs (old: {
      buildInputs = old.buildInputs ++ [ pkgs.libvarlink ];
      src = pkgs.fetchFromGitHub {
        owner = "emersion";
        repo = "kanshi";
        rev = "0faad7544323dfade5def5f9e7f132584cc1cf56";
        sha256 = "sha256-AELUyBa3ZCTRd725lRvIbBxwRFiSYiN0SqtasSGXp1I=";
      };
    }));
};

For the problem of reloading kanshi when sway reload/restart, I am not sure what would be the best solution. It will depend on how sway itself is launched. If sway is launched through a systemd's unit then some systemd magic could be worked out but if it is not, then maybe adding:

exec systemctl restart kanshi.service
# or
exec kanshictl reload

would be the easiest solution. But that would not be very satisfying either.

[berbiche]

systemctl restart kanshi.service

I think we could use systemctl --user try-reload-or-restart kanshi.service in an activation script and once kanshictl is available, the systemd service could have a ExecReload = "kanshictl reload"

[nurelin]

Yeah, I was hoping to find a more general solution. Ideally, sway itself should signal that kanshi needs to reapply its configuration. That is why I was proposing to add an exec directly in sway's configuration.

[nurelin]

Something like:

# services/kanshi.nix
  config = mkIf cfg.enable {
    wayland.windowManager.sway.config.startup = [ 
      { command = "${pkgs.systemd}/bin/systemctl --user reload-or-restart kanshi"; }
   ];
  }

[cyntheticfox]

Something like:

# services/kanshi.nix
  config = mkIf cfg.enable {
    wayland.windowManager.sway.config.startup = [ 
      { command = "${pkgs.systemd}/bin/systemctl --user reload-or-restart kanshi"; }
   ];
  }

This is probably the best stopgap measure imo, but since this display output service isn't particularly tied to Sway, just Wayland, it might be better to have some kind of attrset or list of attrsets at the wayland.windowManager define a list of general restart/start hooks that wayland.windoManager.sway.config.startup could then inherit/join into its own, and include this kanshi reload/restart in.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[g0hl1n]

Something like:

# services/kanshi.nix
  config = mkIf cfg.enable {
    wayland.windowManager.sway.config.startup = [ 
      { command = "${pkgs.systemd}/bin/systemctl --user reload-or-restart kanshi"; }
   ];
  }

Unfortunately this doesn't work for me on NixOS 23.05 with home-manager 23.05 when running nixos-rebuild switch :disappointed:

But running systemctl --user reload-or-restart kanshi in a shell afterwards works... Any ideas?

[MadnessASAP]

Something like:

# services/kanshi.nix
  config = mkIf cfg.enable {
    wayland.windowManager.sway.config.startup = [ 
      { command = "${pkgs.systemd}/bin/systemctl --user reload-or-restart kanshi"; }
   ];
  }

Unfortunately this doesn't work for me on NixOS 23.05 with home-manager 23.05 when running nixos-rebuild switch 😞

But running systemctl --user reload-or-restart kanshi in a shell afterwards works... Any ideas?

add always = true; to the startup submodule. i.e.

{ command = "${pkgs.systemd}/bin/systemctl --user reload-or-restart kanshi.service"; always = true; }

This way sway executes the command every time it restarts, not just the first time.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.