Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manually-started service doesn't shut down on reboot #59

Open
cvincent opened this issue Jan 6, 2024 · 5 comments
Open

Manually-started service doesn't shut down on reboot #59

cvincent opened this issue Jan 6, 2024 · 5 comments
Assignees

Comments

@cvincent
Copy link

cvincent commented Jan 6, 2024

On shutdown or reboot, it takes a very long time if the user xremap service is running because it does not shut down for whatever reason. The shutdown process gets stuck at A stop job is running for User Manager for UID 1000 and it takes about 4 minutes before systemd finally forces it down. If I remember to manually stop the service before reboot, the reboot process proceeds normally without this delay.

My configuration is the same as in the conclusion to this previous issue: #43

Possibly related:

My setup uses GDM as a display manager which then launches Hyprland when I log in. I found that the service didn't automatically start, or rather it would die when it tried to start on its own (I believe it was a broken pipe error but unfortunately my logs don't go far back enough to confirm). So I just added exec-once = systemctl --user start xremap to my Hyprland config and called it a day. This works just fine except that I suspect it might be related to systemd not properly shutting it down on reboot.

I'm wondering if setting a wantedBy might fix both issues, but I'm not sure what to set it to for my setup.

Thanks again for any help, and again for packaging this awesome tool.

@cvincent
Copy link
Author

cvincent commented Jan 6, 2024

Looking at my systemd units, it looks like what I actually want might be graphical.target, rather than graphical-session.target. Unsure how to set this in my config, tried a couple things that didn't work. Looking at the source for this flake, it looks like wantedBy might actually be hardcoded for the home manager module?

@VTimofeenko
Copy link
Contributor

A workaround for hanging user processes could be services.logind.killUserProcesses (NixOS options).

My configuration is the same as in the conclusion to this previous issue
To clarify -- which hyprland module are you using?

  • programs.hyprland from nixpkgs
  • wayland.windowManager.hyprland from home-manager
  • Importing one of the modules from hyprland flake?

I'm wondering if setting a wantedBy might fix both issues, but I'm not sure what to set it to for my setup.
It, along with partOf setting, could be the fix here, yeah.

it looks like wantedBy might actually be hardcoded for the home manager module?
you could try lib.mkForce to override this, like so:

# For home-manager only
{ lib, ... }:
{
  systemd.user.services.xremap.PartOf = lib.mkForce [ "graphical.target" ];
  systemd.user.services.xremap.After = lib.mkForce [ "graphical.target" ];
  systemd.user.services.xremap.Install.WantedBy = lib.mkForce [ "graphical.target" ];
}

If this works, the session name should be exposed as a module option with default set to "graphical-session".

@VTimofeenko VTimofeenko self-assigned this Jan 6, 2024
@cvincent
Copy link
Author

cvincent commented Jan 7, 2024

To clarify -- which hyprland module are you using?

I'm using programs.hyprland per Hyprland's NixOS install recommendation, though I am setting the URL in my flake.

I have a partial fix and a good-enough-for-me workaround. Adding the following to my HM config:

{
  # Slight correction of the above, `.Unit` was missing
  systemd.user.services.xremap.Unit.PartOf = lib.mkForce [ "graphical.target" ];
  systemd.user.services.xremap.Unit.After = lib.mkForce [ "graphical.target" ];
  systemd.user.services.xremap.Install.WantedBy = lib.mkForce [ "graphical.target" ];
}

This fixes the stop job issue on reboot. Sick!

However, it did still fail after boot, seemingly the first time it saw an app, with the following (Keyboardio, btw):

Jan 07 10:28:13 nether xremap[2106]: application-client: wlroots (supported: true)
Jan 07 10:28:13 nether xremap[2106]: application: kitty-scratch
Jan 07 10:20:29 nether xremap[2121]: Failed to grab device 'Keyboardio Model 01 Keyboard' at '/dev/input/event21' due to: Device or resource busy (os error 16)
Jan 07 10:20:29 nether xremap[2121]: Failed to grab device 'Keyboardio Model 01' at '/dev/input/event23' due to: Device or resource busy (os error 16)
Jan 07 10:20:29 nether systemd[1899]: Stopping xremap service...
Jan 07 10:20:29 nether systemd[1899]: Stopped xremap service.

Yet leaving this in my hyprland.conf works around it just fine:

exec-once = systemctl --user start xremap

I can live with this, but happy to continue answering any questions!

@VTimofeenko
Copy link
Contributor

I'm using programs.hyprland per Hyprland's NixOS install recommendation, though I am setting the URL in my flake.

Are you using home-manager to configure hyprland? If so, wayland.windowManager.hyprland.systemd.enable adds a graphical-session.target where xremap binds to. That might take care of "failed to grab device" race.

Alternative:

Yet leaving this in my hyprland.conf works around it just fine:

exec-once = systemctl --user start xremap

If this works, you might get rid of the initial start by setting

systemd.user.services.xremap.Install.WantedBy = lib.mkForce null;

Which should force hyprland (and not your systemd user instance) start xremap.

@cvincent
Copy link
Author

cvincent commented Jan 7, 2024

I'm not currently using home manager to configure Hyprland as I'm still in the process of moving my configs over from my old Arch setup. For the time being, I'm happy with how it's currently working with the workaround. I appreciate the help again, and hopefully this thread can help others in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants