zlacker

[return to "Nitro: A tiny but flexible init system and process supervisor"]
1. andrew+Dj[view] [source] 2025-08-22 20:59:59
>>todsac+(OP)
I'm always torn when I see anything mentioning running an init system in a container. On one hand, I guess it's good that it's designed with that use case in mind. Mainly, though, I've just seen too many overly complicated things attempted (on greenfield even) inside a single container when they should have instead been designed for kubernetes/cloud/whatever-they-run-on directly and more properly decoupled.

It's probably just one of those "people are going to do it anyway" things. But I'm not sure if it's better to "do it better" and risk spreading the problem, or leave people with older solutions that fail harder.

◧◩
2. bityar+cp[view] [source] 2025-08-22 21:33:39
>>andrew+Dj
Yes, application containers should stick to the Unix philosophy of, "do one thing and do it well." But if the thing in your docker container forks for _any_ reason, you should have a real init on PID 1.
◧◩◪
3. RulerO+xa1[view] [source] 2025-08-23 04:02:08
>>bityar+cp
> you should have a real init on PID 1

Got a handy list of those? My colleagues use supervisord and it kinda bugs me. Would love to know if it makes the list.

◧◩◪◨
4. bityar+638[view] [source] 2025-08-25 21:50:04
>>RulerO+xa1
If all you need is init (and not a process supervisor), docker comes with one called 'tini' built in. All you have to do is supply `--init` to the `docker run` command. Or use `init: true` in your docker-compose.yaml.

As far as a different process supervisor, I'm not sure. I've used supervisord and agree it's kind of awkward. I have heard of these but don't know much about them:

https://smarden.org/runit/

https://github.com/nicolas-van/multirun

https://github.com/just-containers/s6-overlay

◧◩◪◨⬒
5. RulerO+1kn[view] [source] 2025-08-30 21:32:06
>>bityar+638
I'm a fan of s6 after getting exposed to it through the Linuxserver.io project... but I'm not certain it's appropriate when you're using an orchestrator like k8s.

Take health checks for example. I can't decide—in principle—if they should live at the highest level, the lowest level, or every level of the stack. Or if they are everywhere, should there be automated remediation with exponential trigger times... stuff like that. S6 and supervisord would be good for that. But higher-level remediation steps make something simpler more appealing.

[go to top]