From 047befef9b8ef074d34b05e294d753f6c2751987 Mon Sep 17 00:00:00 2001
From: Laurent Bercot
s6-rc -a list+ +
s6-rc -d list+
or
+s6-rc-db list services+ +
s6-rc -u change foo+ +
s6-rc -da change+ +
s6-rc-db -u script foo | xargs -0 printf "%s "+ +
s6-rc-db pipeline foo+ +
s6-rc-db -d all-dependencies foo+ +
s6-rc-update -n newcompiled+ +
+ The first line is the s6-rc invocation that +will bring the old services down. The services that will stop are listed +after -- change. + The second line is the s6-rc invocation that +will bring the new services up. The services that will start are listed +after -- change. +
Because parsing sucks. Writing parsers is an annoying, ungrateful task, @@ -37,16 +86,17 @@ file.
Using the filesystem as a key-value store is a good technique to avoid parsing, and skarnet.org packages do it -everywhere: for instance, look at -s6-envdir. +everywhere: for instance, +s6-envdir +uses the file name as a key and the file contents as a value. The s6-rc-compile source format is just another instance of this technique.
- This format generally plays well with automated tools, be it for + The source format generally plays well with automated tools, be it for reading, as s6-rc-compile does, as for writing. -I fully expect the s6-rc-compile source format +I fully expect it to be used as the input (resp. the output) of some automated tools that would convert service definitions to (resp. from) another format, such as systemd @@ -55,17 +105,19 @@ s6-rc source format will make it easy on those tools.
- And if you love configuration files, don't mind writing a parser (which is + And if you love configuration files, are ok with writing a parser (which is indubitably easier to do in other languages than C), and want to write a program that takes a text file, parses it and outputs a service -definition directory, it should also be rather easy. +definition directory in the s6-rc-compile source format, it should also be +rather easy - please, feel free!
- Use bundles. Bundles are awesome. + Use bundles. Bundles are the solution to most of the questions in +the same vein.
@@ -84,7 +136,7 @@ will resolve to opensshd, and the compiled service database will consider opensshd to be the "real" service; but users will still be able to run s6-rc commands involving sshd. -And if users want to change the default to dropbear, just +And if you want to change the default to dropbear, just change the sshd/contents file to dropbear, recompile the database, and run s6-rc-update. @@ -113,7 +165,7 @@ one of them.
Yes. @@ -163,7 +215,7 @@ you fix it.
- You have better than runlevels. You have bundles. + You have better than runlevels. You have bundles.
@@ -209,11 +261,57 @@ for. When in doubt, use bundles.
++ Because those intermediate states are unnecessary. +
+ ++ From the machine's point of view, things are simple: a service is +either up or it's not. If a service fails to start, then it's still +down. Note that it is recommended to write atomic oneshots +for this very reason. +
+ ++ Service managers that use intermediate states do so in order to keep +track of what they're doing and what they have done. But this +introduces needless complexity: the reality is that the service is +either up or down, it's either in the state you wanted it to be or +not. A model should not be more complex than the reality. +
+ ++ s6-rc does not keep track of "failed" states: a service that fails +to start simply remains down, and +s6-rc exits 1 to report that something +went wrong. To know what services failed to start, compare the +result of s6-rc -a list against your expected machine state. +
+ ++ The reason for this design is simple: if the +s6-rc process is killed in the middle of a transition +while a service state is "starting", what should the next invocation do? +This is unclear, and the intermediate state introduces ambiguity where +there should not be. Also, +if there is a "failed" service, what should the next invocation do? Try +and restart it, or not? This depends on what the user wants; this is +policy, not mechanism. Simply reporting the error while keeping the +state as "down" allows users to apply their chosen policies - see below. +
+ ++ Keep it simple, stupid. +
+In the world of software development, it is important to distinguish @@ -248,7 +346,8 @@ distributors' job! for a Linux distribution, so with that in mind, the OpenRC developers did not have to think much about separating mechanism from policy. It works very well for Gentoo and Gentoo-derived distributions; but it -requires more work to use OpenRC outside of that frame. +requires adaptation and more work for the admin to use OpenRC outside of +that frame.