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

Add Gunicorn to nginx_shell.nix #23

Open
toraritte opened this issue May 23, 2023 · 0 comments
Open

Add Gunicorn to nginx_shell.nix #23

toraritte opened this issue May 23, 2023 · 0 comments

Comments

@toraritte
Copy link
Member

toraritte commented May 23, 2023

There is a just recipe for Gunicorn, but NGINX operationally depends on it, so it makes sense to start Gunicorn before NGINX is fired up.

The current method in dev is:
0. nix-shell ... dev_shell.nix

  1. just gunicorn_local 8000 &
  2. nix-shell ... nginx_shell.nix

The problem with this is that shells are being stacked (a lot) and when tearing them down, gunicorn never stops on its own.

This would work in a shell.nix too, but clean-up would be painful:

  • Gunicorn does save its PID in a pidfile, but the problem is that there can be multiple one present, so which one is the actual one? just gunicorn assigns a name dynamically based on a timestamp.

  • jobs -p shows the PID of the jobs, but would this work in a shell.nix as well? (Caveat: none of the PIDs in the pidfiles will match the output of jobs -p because Gunicorn is started using an intermediary, just, therefore it will have a parent.)

Options:

  • Use systemd.

    No PID-lookup shenanigans, only a single command - but what if multiple instances needs to be fired up? (For whatever reason.)

  • Call Gunicorn directly, without just.

    This way, the reference to the pidfile can be retained and directly used in the clean-up phase. (I don't think that it needs to be save in a shell variable, because the after constructing the pidfile's name, every reference to it in the shell.nix will work the same as being in a closure.

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

1 participant