Several suggestions and questions about s6-overlay

[glerchundi]

1. Don't build four tarballs by default. Make no debug linux the default, and check environment variables for build the portable or debug versions. Also, document the differences between these versions.

When I created this project, It was thought to cover not only docker images but a wider range of linux distros using a common s6-based init system. I think this is no longer true and it's really focused on docker so probably It's enough with s6-overlay-portable and s6-overlay-portable-dbg. I need time to think about that but probably we'll be releasing just one tarball. It'll be easier to make a choice.

A far better generic init system for linux distros is being written see this discussion by Olivier Brunel & Laurent Bercot:
http://www.mail-archive.com/[email protected]/msg00594.html

2. Don't include all s6 utilities by default, only the subset actually used by the init scripts.

We're already doing that, s6-portable includes required binaries to get a s6-based init system up and running.

3. It's a bit confusing that you're bringing in a package from your other skaware-builder repo. I'm assuming this is just the s6 source? Could you pull it from an official location instead?

No. It's not s6 source. It's a repo for retrieving & building & publishing s6 tools including execline. It'll publish statically linked binaries (zero-dependencies), ideal for distribution.

4. Why does /init wrap /etc/s6/init/init-stage1? It's an extra layer of indirection, can this be replaced with a symlink?

No. Symlinks don't work very well when it comes to packaging into a tarball.

5. The flow from /etc/s6/init/init-stage1 -> /etc/s6/init/init-{catchall,no-catchall}/init-stage1 -> /etc/s6/init/init-{catchall,no-catchall}/init-stage2 -> /etc/s6/init/init-stage1 is confusing. Perhaps the middle steps could renamed stage1-post and stage2-pre, or conditionally imported into the main scripts?

Nope. I wanted to exist both versions explicitly because they are quite different. They are "conditionally imported" already using S6_LOGGING.

6. What does the "vital fifo" /var/run/s6/services/s6-fdholderd/supervise/control do?

These are really interesting readings, they will help you understanding why that "vital fifo" is so vital:

• http://skarnet.org/software/s6/overview.html
• http://skarnet.org/software/s6/s6-svscan-1.html

7. Why are some services in /etc/s6/services and others in /etc/services.d? Can they be merged to a single location?

/etc/s6/services are the ones provided by s6, I call them "system services". /etc/services.d instead is the place where you should put your own services, that ones are called "user services". Both kind of services are merged into the runtime services folder which is located in /var/run/s6/services, that folder is guaranteed to be read/write. The reason of having two different services folder is because probably user controlled services wants to use system services. Take a look to this example:

https://github.com/just-containers/nginx-loadbalancer/blob/master/rootfs/etc/cont-init.d/00-initialize-log-fds#L4

8. I assume no-catch-all is inaccurately named, and actually does catch all, but logs everything to stdout/stderr?

haha. no-catch-all doesn't mean don't catch all, it means don't use catch-all logger.

9. I'm going to attempt to boil down your scripts to the simplest possible version (mentioned this on the mailing list). I'd really appreciate it if you could review them when I'm done!

Writing a custom and rock-solid init process is an art. These init scripts were mostly written by Laurent Bercot (@skarnet) who really, really, really knows and understands how everything works under the hood. So I'll recommend you to not to do so, because I think they are already the simplest they can be!

10. Why is only init-stage2-redirfd broken out into its own separate file? Either all of the sections of stage2 should broken out, or none.

Because it's not easy to conditionally change the flow of a script written in execline:

http://www.mail-archive.com/[email protected]/msg00310.html

11. Could init-stage3 be moved to .s6-svscan/finish?

Yes but in order to keep everything organized I prefer to create a direct call to .s6-svscan/finish.

I appreciate your comments, expect a FAQ section in the README and some comments about release tarballs.

[dreamcat4]

On Tue, Apr 21, 2015 at 8:05 AM, Gorka Lerchundi Osa <
[email protected]> wrote:

this is no longer true and it's really focused on docker so probably It's
enough with s6-overlay-portable and s6-overlay-portable-dbg. I need time
to think about that but probably we'll be releasing just one

May I suggest a rename? Here are some options:

# docker
s6-overlay-portable --> s6-overlay-docker
s6-overlay-portable --> s6-overlay-dkr

# generic
s6-overlay-portable --> s6-overlay-min
s6-overlay-portable --> s6-overlay-mini
s6-overlay-portable --> s6-overlay-minbase

5. The flow from /etc/s6/init/init-stage1 ->
   /etc/s6/init/init-{catchall,no-catchall}/init-stage1 -> /etc/s6/init/init-

Nope. I wanted to exist both versions explicitly because they are quite

different. They are "conditionally imported" already using S6_LOGGING.

8. I assume no-catch-all is inaccurately named, and actually does catch
   all, but logs everything to stdout/stderr?

haha. no-catch-all doesn't mean don't catch all, it means don't use
catch-all logger.

& here. Perhaps a rename:

catch-all ---> s6-logging and s6-no-logging.

To make it more consistent with the renamed ENV variable S6_LOGGING. It
only matters for people who look inside the code.

[glerchundi]

Yes, I'm thinking on releasing just two tarballs: s6-overlay & s6-overlay-dbg this will avoid any confusion.

Internals should be kept as clean as possible and because s6 literature references this as catch-all logger (here & here) i'm not gonna change it.

but thanks anyway!