You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
just gunicorn_local 8000 &
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.
The text was updated successfully, but these errors were encountered:
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
just gunicorn_local 8000 &
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 ashell.nix
as well? (Caveat: none of the PIDs in thepidfile
s will match the output ofjobs -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 thepidfile
's name, every reference to it in theshell.nix
will work the same as being in a closure.The text was updated successfully, but these errors were encountered: