On Fri, 10 Apr 2015 18:41:45 -0700 Aristomenis Pikeas <pik...@gmail.com> wrote:
[snip] > For a bit of context, my goal is the simplest init system that could > possibly work, to be run inside of a docker container. <warning>Everything I say here is sort of academic. Also, a lot of the things I say about daemontools are probably true of s6 too.</warning> Hi Aristomenis, I always thought the simplest possible init system is Rich Felker's init; the one whose listing is at the bottom of this blog entry: http://ewontfix.com/14/ Theoretically, Rich Felker's init is all you need in order to init, pushing things like process management to be run by /etc/rc or whatever you want to call that shellscript. I was able to init with Rich Felker's script going to OpenRC for process management (such as it is in OpenRC), but there were problems with reboots requiring journal restores, and other problems. It's surprising I didn't attempt to use Rich Felker's init to run daemontools or daemontools-encore, with /etc/rc doing things like starting udev (or vdev or whatever) and devfs and network initialization, and finally running daemontools (via svscanboot) to manage processes such as virtual terminals and daemons. As far as sending all log messages to stdout, I don't know if daemontools can do that, but I know daemontools can send all log messages to the same file, assuming the daemontools log run scripts are configured to do that. > I need to > start services and gracefully handle SIGTERM/SIGKILL, with everything > logged to standard out. That's about it. But this is proving to be > difficult with s6. Daemontools correctly handles SIGTERM/SIGKILL, if by "correctly" you mean restarting it. With daemontools (and I believe s6 too), the way to stop a daemon is with the svc -d command. > I've been chipping away at things, but it's slow > going between understanding all of the tricky bash-isms and learning > about all of the relevant s6 components. I'm under the impression that s6 offers use of the execline language as a way to avoid bash-isms. I found execline's documentation insufficient for me to learn it, but my impression is its purpose is to provide you with a language that's less tricky and more determinant and more versatile than bash. > If any of the four of you, or anyone else on this list, could provide > some guidance, I'd greatly appreciate it. I'm convinced that s6 is a > better solution than runit, but at this point I may switch back, as > things mostly Just Work. I think s6 has a documentation problem. I compiled it, but was never able to get it to run, mostly because I was unable to find, in the docs, what to do after I got it compiled. And there were way too few examples of execline code, and I couldn't figure out the language logic from the descriptive diagrams. As far as s6 vs runit, my impression is that s6, runit, nosh and perp are all daemontools-influenced inits that, relative to the entire constellation of inits out there, are all excellent and very similar to each other. Runit happens to be the one I was able to actually get running, but if I were as systems-programming smart as the average person on this list, I'm sure I could have gotten all four running. And once again, all of them have documentation problems. Once runit, s6, perp and nosh have documentation useful for the average person, the world will be a wonderful place. By the way, if you're looking for a simple init, consider Epoch: http://universe2.us/epoch.html . In my opinion it's the best documented of all init systems, and in my opinion it's the quickest and easiest to get running on any old random Linux machine (can't run on BSD, but neither can docker). Unfortunately, it's not daemontools derived and therefore doesn't manage processes in the foreground with all the advantages foreground management confers. And it spawns processes consecutively, by number, rather than concurrently, so you might not want to use it to init something with fifty daemons. But it's still pretty good, and it's a good learning tool, IMHO. SteveT Steve Litt Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28