On Fri, Oct 28, 2016 at 3:00 PM akhiezer <[email protected]> wrote: > > (lightcube os, or roundcube os ?). >
Yes, it used to be called lightcube os, but I changed the name to merelinux sometime after I switched to musl libc and pacman. > In your experience: if, say, a server daemon crashes, then how well, > if at all, does s6: > Most of the answers for below are simply implementation details. Meaning, s6 itself has support for as much or as little configuration as you like to handle all of these cases, but it's up to you as a user or distributer to make use of the hooks provided. > -- > * clean-up the debris; > This depends on what you mean by debris. As a parent process, it will handle the appropriate signals and reap the child resources as it should, but it's not going to get bogged down by some specific state that a service may or may not leave behind on disk. It itself doesn't need pid files and the like to track the state of a service, but it's not going to clean up the disk if a service thinks it needs to create one for its own purposes. That's not really its job. It can, however, be configured to handle starts and exits in any fashion you like because it signals events to special fifos which you can attach listeners to. http://skarnet.org/software/s6/s6-supervise.html > * restart the daemon cleanly; > and handle properly and dependent-daemon stuff; * avoid getting into a (runaway) loop of persistent crashes; > * log info on the above stages; > * notify root/&c of the above. > I think most of the above is answered as well by the hooks and handles s6 provides, but at its core, it is just a simple supervision suite. Meaning that if you specify that a service should be up, it's going to keep trying to bring it up, unless you tell it to stop. As mentioned, though, there are event interfaces that can be used to notify that a service is bouncing and even take automated action in that case, in whatever way you configure it. Logging with s6 is interesting. You can, of course, spin up a syslog daemon and have it capture all things being sent to the /dev/log socket, but s6 comes built with tools and interfaces to use a different take on logging. Basically, the idea is that each service can have its own dedicated process to log (and rotate) output. You keep the service running in the foreground (because it's supervised) and have it log to stderr, which is then piped to the dedicated log process as input. The author writes about it better than I could, here: http://skarnet.org/software/s6/s6-log.html The reasoning is spelled out about 2/3rds of the way down under the section 'Why have another logging mechanism?' Hope that answers your questions... JH
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
