System process supervision is a funny thing. Seems to get perpetually re-invented.
This is a pure shell implementation and minimalist design, so that’s interesting. For supervision of production apps, I prefer supervisord, which is written in Python. Has extensive documentation here:
The main advantage of supervisord, and why it’s used by so many folks for supervising long-running apps in a production environment (e.g. on cloud nodes), is that it is common to run supervisord as a normal UNIX user rather than as root. Inspecting supervisorctl output is a great way to know what custom processes are running on a machine. I tend to think of the “system-level” supervisor (e.g. systemd) as an “implementation detail” of the host OS and standard-installed software packages, by contrast.
I’d been a fan of supervisord for many years but a few points have soured the experience.
not sure if that was a bug, but inheriting number of open files was weird/buggy/hard to debug and cost me many hours
I have a box with openresty and supervisorctl is simply not able to reliably stop this process
I did have some problems with reloading changed config files in the past.
So overall not too much, but too many oddities and bugs for something so basic. Also I discovered that systemd for process supervision (mostly restarting) isn’t actually so bad, and it’s one less piece of extra software if you have systemd anyway.
This is not a supervisor in the daemontools, runit and s6 sense.
It doesn’t actually use signals to notice when a child process dies, is prone to the same issues issues as PID files (sending SIGTERM to wrong processes on pid reuse).
System process supervision is a funny thing. Seems to get perpetually re-invented.
This is a pure shell implementation and minimalist design, so that’s interesting. For supervision of production apps, I prefer
supervisord, which is written in Python. Has extensive documentation here:http://supervisord.org/
The main advantage of
supervisord, and why it’s used by so many folks for supervising long-running apps in a production environment (e.g. on cloud nodes), is that it is common to runsupervisordas a normal UNIX user rather than as root. Inspectingsupervisorctloutput is a great way to know what custom processes are running on a machine. I tend to think of the “system-level” supervisor (e.g.systemd) as an “implementation detail” of the host OS and standard-installed software packages, by contrast.People forget systemd can be used at the user level too.
I’d been a fan of supervisord for many years but a few points have soured the experience.
So overall not too much, but too many oddities and bugs for something so basic. Also I discovered that systemd for process supervision (mostly restarting) isn’t actually so bad, and it’s one less piece of extra software if you have systemd anyway.
And without systemd… daemontools work fine.
You can run ‘runit’ as a normal user as well.
This is not a supervisor in the daemontools, runit and s6 sense.
It doesn’t actually use signals to notice when a child process dies, is prone to the same issues issues as PID files (sending SIGTERM to wrong processes on pid reuse).
Might as well throw the one I wrote into the ring:
https://github.com/andrewchambers/orderly/
It’s designed to be run by a user and create a supervisor tree hierarchy inspired by erlang OTP.