Re: s6 + Docker init feedback

From: Aristomenis Pikeas <>
Date: Wed, 22 Apr 2015 15:37:26 -0700

> On Apr 22, 2015, at 14:34, Laurent Bercot <> wrote:
> "Hey, I took your work, gutted it, removed all the flesh, and kept the
> skeleton. Have I broken anything ?"
> Well... tell us. Try it! Is it working? Does it do what you want it to?
> If it does, great. If it doesn't... maybe you should put a little flesh
> back on.

Er...this seems rather hostile? Is trying to simplify existing code for my needs a bad thing? Is it wrong to ask for help when I'm unsure I've done it right? I removed all of the "fresh" I thought I could, but that doesn't mean I did so correctly! I'm asking this list, and you, because you're much more familiar with init systems generally, and s6 specifically, than I am.

> Remember that s6-overlay is something generic, that aims to be used in
> a wide variety of situations, so there's code to handle a lot of cases.
> If it's too generic for you, by all means, take out what you don't need,
> build your own minimal script, but don't ask us "is it good?" afterwards!
> If it was good for our needs, it's what we would have done instead of
> the more complex overlay. :P

I didn't mean to imply I was asking "is it good (for everyone)?" I'm asking, "does this do what I think it does/what I want it to do?".

> The thing is, for instance this simple requirement:
>> - Ability to run services only, or services + given command.
> generates more complexity than you think. You actually want to run the
> command in an environment you control, and give to your "docker run"
> invocation; but you do not want to run the supervision tree with that
> environment, because if you do, then the behaviour of the supervision
> tree depends on variables that a user can define! It's even worse with
> terminals. You definitely do not want to run the supervision tree with
> the same controlling terminal as your given command!

This is actionable feedback, thank you! My takeaway is that I went too far in removing the environment sanitization, which I'll rectify.

> Even without controlling terminals: you commented out the
> "redirfd -r 0 /dev/null" line in stage 1. That means your supervision tree,
> and all your services, will run with stdin pointing outside the container.
> The same stdin that will be given to the command. If one of your services
> mistakenly reads from stdin, it's game over.

Excellent, thank you for the catch and the explanation.

> You put your scandir in /etc/services. Can you guarantee that it will
> always be correct, containing exactly the service directories you want,
> with the right permissions, and that it will be mounted read-write?
> Maybe you can guarantee it for your case, and that's great; but we cannot
> guarantee it in general, because the overlay can be used with a whole
> variety of systems, including very braindead ones, and we wanted it
> hardened.

Yes, I can make those guarantees in this case. Can you recommend any changes for failing loudly if this should prove incorrect in the future? This is preferably to silently fixing file and directory attributes as s6-overlay does currently.

> So... "does it work?" In the general case, no, it doesn't. In your case,
> maybe it does - you're the only one who can tell. So please try it and
> do tell :)

I *think* it works. But I'm in a position where "I don't know what I don't know", which is why I asked for help on this list. :-)

Received on Wed Apr 22 2015 - 22:37:26 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC