-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
separate swhkd and swhks systemd service #144
Comments
If you don't want to depend on forking, you can use control group to launch commands, though I think swhkd should be vendor agnostic and should not depend on any init system to launch commands on its own. Therefore, you have to wrap your own commands with a wrapper that create a control group behind the scene, so without forking other processes would still run even when you stop swhks service. I will leave this for comments, since I don't know of a better way to do this.
- I totally agree that a tool like swhkd should be 100% init system independent.
- Do you think we should create a cgroup right on startup of swhks and then fork into it?
- I'm not too familiar with cgroup syscalls so if you think you can expand on this by patching it into swhks, I'd be more than happy to merge it.
|
Note that I also haven't really figure out how to terminate shkwd via systemd. Granted, you can reload, pause loading or continue loading config file with HUP or USR signals, but systemd sending SIGTERM just won't do it. Probably because swhkd is running with pkexec. |
I think so, though I'm also not familiar with cgroup syscalls. Let's just hope something else come up while I'm getting used to the syscalls. |
I have a working example here:
This approach has
KillMode=process
, which depending on your concerns might be a bit out of control. After all, systemd.kill(5) don't recommend setting kill mode to only the process itself, as the manual mentions the need for cleaning up child processes after main process exited.With that said, swhkd does actually detach the child process after launching, it's just that with systemd, the child is still contained in swhks control group even after detaching. This could make them crash if all of a sudden swhks crashes, or is terminated. Setting service type to forking fixes this problem, though I believe this would open another can of worm before we even get to a proper solution.
If you don't want to depend on forking, you can use control group to launch commands, though I think swhkd should be vendor agnostic and should not depend on any init system to launch commands on its own. Therefore, you have to wrap your own commands with a wrapper that create a control group behind the scene, so without forking other processes would still run even when you stop swhks service. I will leave this for comments, since I don't know of a better way to do this.
The text was updated successfully, but these errors were encountered: