3 ms·
I was super stoked to read this, and went diving to borrow some of their work for my own Docker usage. However, I'm confused by their choice of Python for the m
by akerl_ 13y ago
I was super stoked to read this, and went diving to borrow some of their work for my own Docker usage. However, I'm confused by their choice of Python for the my_init script. The site claims they chose runit because it is more lightweight than supervisord, a Python tool of similar merit. Making the init process depend on Python seems to negate that advantage.
- FooBarWidget 13y agoIt's not only Python that makes supervisord relatively heavy compared to runit. It's also the amount of code in supervisord (and its dependencies). my_init is only a single file, less than 300 lines, with minimal dependencies. Baseimage-docker is also in a "minimal viable product" phase. We're still trying to tweak things until they're right. For example my_init recently received some features which are important in certain use cases; features which would have been much lower to implement in C. In the future we may optimize things by rewriting my_init in C. Right now it's laziness on our part.
- akerl_ 13y agoBased on the points raised in your article, I ended up poking my own Docker images to get runit working on them. It looks like runit is A) pretty snazzy, and B) capable of being the init daemon. Am I missing some trade-off or issue there, that prevents it from being PID1 in your scenario?
- FooBarWidget 13y agoYes. Runit does not correctly reap adopted child processes, which is why we run runit under my_init. My_init (or an alternative that behaves like my_init) is absolutely necessary for correct operation.