-
Notifications
You must be signed in to change notification settings - Fork 75
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
modules/supervisord: init, modules/openssh: init #203
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks cool, will continue the review later :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review! I'll squash the commits once everything is ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also mention the new modules in the changelog :) Would be great to have some tests for these new options (if feasible with reasonable effort).
Wanted to implement something like that since a very long time, I am glad you took the effort. Thank you a lot :)
${lib.optionalString config.supervisord.enable '' | ||
set +e | ||
if [ ! -e "${config.supervisord.socketPath}" ]; then | ||
${config.supervisord.package}/bin/supervisord -c /etc/supervisord.conf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are starting the daemon but you should also stop it, when every shell is closed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to do, but I'm not sure what the cleanest way to do that is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see myself doing an 'Acquire wakelock', closing all shells and still expecting services to run, so not sure what's the ideal UX here. My vote is "notification is present <=> services are running".
What's the current situation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is worth providing solutions to both use cases, so there could be an option to disable automatic shutdown after last session closes (I think using automatic shutdown as default sounds safer than the other way around).
But also not quite sure where such a shutdown could be implemented..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could replace exec proot
in /bin/login
with a fork and wait approach while redirecting process signals to the proot process, enabling us to run cleanup stuff after a session is closed. Counting of proot processes could then be used to shutdown supervisord. I can not think of a downside of this approach (and I don't see an alternative).
For completion, it would be great to have native options to add ssh pub keys in |
Tested it on device: Running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested it on device: Running
supervisorctl stop sshd
does not stop the sshd process when there is an active ssh session.. Does not look like that would be expected behaviour.
It's expected behavior because sshd forks a separate process to handle each connection. You can try by stopping sshd on NixOS (or any other distro): Existing sessions keep running but you can't establish new ones.
But yes, we do need to consider whether to want to terminate everything when all foreground Nix-on-Droid sessions exit. In regular Termux my manually started sshd processes still run when all sessions end.
''; | ||
type = types.str; | ||
}; | ||
script = lib.mkOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
command
is the direct way of specifying what to run (systemd.services.<name>.serviceConfig.ExecStart
) and works fine for simple services that don't require much setup. I think there's no need to involve a script when setting command
directly is sufficient (also avoid the exec
pitfalls).
${lib.optionalString config.supervisord.enable '' | ||
set +e | ||
if [ ! -e "${config.supervisord.socketPath}" ]; then | ||
${config.supervisord.package}/bin/supervisord -c /etc/supervisord.conf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to do, but I'm not sure what the cleanest way to do that is.
Okay, but there is still a sshd process running even after the last ssh connection is closed when the sshd was stopped while session where open. |
Otherwise mkdir et al may silently fail.
This matches the behavior of makeJobScript in nixos/lib/systemd-lib.nix.
711e4f3
to
56f4e44
Compare
Doesn't exist in stable.
This removes the 1-second delay between supervisord starting and forking into background.
There is another UX issue with the current approach. Currently |
Why not detach the process from the invoking session with e.g. disown? |
Sadly this can't work because proot needs to ptrace all processes in the session to perform its hooking, so it has to be there as long as any child processes exist. There doesn't appear to be an option to have proot itself fork into the background if the "main process" exits. |
Random idea, feel free to disregard:
|
That's what I meant by "start supervisord in a separate proot invocation." If this is desired I'll implement it later this week. |
I still somehow thought that meant starting it from proot with extra precautions. Sorry for the noise then. As for desireability, I'm not sure. Sounds rather involved to me wrt starting/stopping it (via signals?). If you figure out some alternative that simplifies things at the expense of, say, some support from the app, I'm open for discussing it further. |
Hey @zhaofengli , is there anything where I could support you with this PR? :) |
Sorry, got distracted and forgot about this :/ Termux does appear to have a special type of session for background tasks: One integration is implemented in Termux:Widgets, where you can drop a shell script in |
Is there a way to test this PR without rebuilding the fork? Maybe a way to patch these modules into the config? |
Yes, either use @zhaofengli's fork as channel/flake input or create your own fork of nix-on-droid and rebase his branch onto latest master to keep all changes that were merged in the meantime. No need for a new bootstrap zip because there were no changes :) |
Sorry for being off-topic; how would I do this, exactly? I'm currently not using Flakes. Do I swap the Nix channel with one that points to this commit? |
nix-channel --list shows you the current nix-on-droid url. That's a url with repo owner, repo name and rev (probably master or release-22.11). Replace owner and rev and set within .nix-channels, afterwards run nix-channel --update and nix-on-droid switch :) |
fi | ||
'')} | ||
|
||
exec ${cfg.package}/bin/sshd -D -f /etc/ssh/sshd_config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably add the -e
flag so log output goes to stderr, which supervisord can actually pick up (unlike syslog).
What's the status of this PR? I've been using it for some basic services and I'm pretty happy with it. Would be good to get it merged if possible. |
Another friendly ping. Any progress on this? |
This PR adds support for running services with supervisord as well as an OpenSSH module. I wanted to run an SSH server (#32, #156) that gets automatically launched when Nix-on-Droid starts, complete with process supervision.
The
supervisord.programs.<name>
options are designed to resemblesystemd.services.<name>
:Fixes #54.