Apologies to Laurent who is about to get this one twice. On Mon, Apr 27, 2015 at 12:48:58AM +0200, Laurent Bercot wrote: > I'll probably add an automatic bundling feature for a daemon and its > logger; however, a oneshot to create a chroot directory? That's too > specific. That's not even guaranteed portable :) (chroot isn't in Single > Unix.) If you want a change from the default daemon+logger configuration, > you'll have to manually set up your own bundle. > OpenSSH, at least on Linux and *BSD, chroots into an empty directory after forking for your login. That was an example but I think the question is still valid: if you have a logical grouping of longrun foo, longrun foo-log, and a oneshot helper bar, where foo depends on foo-log and bar, does s6-rc automatically create a bundle contaning foo, foo-log, and bar? In the grand scheme of things it doesn't matter since regardless of the method used to start foo, s6-rc will start foo-log and bar due to the dependency graph. However, I still think it's a reasonable question since it sheds light into the expected method of grouping longruns and oneshots.
In hindsight, this question could probably have been better asked as follows: "does s6-rc automatically create bundles for each complete dependency chain?" If it doesn't that's totally fine, I'm just trying to suss out implementation and interaction details well before the ship date. Actually, it's probably better if automatic bundle creation doesn't happen beyond daemons and their loggers, since otherwise we'll end up with totally dumb bundle names like: "nginx+nginx-log+php-fpm+php-fpm-log+syslogd+syslogd-log+mysql+mysql- log+net-enable\(boot\)_bundle" :) > > What do you mean by user-supplied dependencies ? Every dependency is > basically user-supplied - in the case of a distro, the user will be the > packager, but s6-rc won't deduce dependencies from a piece of software > or anything: the source will be entirely made by people. So I don't > understand the distinction here. > It's mostly a distinction of "does service foo start but maybe not do the right thing if bar isn't running" (httpd and php-fpm) vs. "does service foo crash if bar isn't running" (basically everything that depends on dbus). And yes, in the end everything is user supplied, be it at the programmer, distro, or end user level, but some people feel like those differences necessitate using different terminology as well. For the record, I don't particularly feel like those distinctions warrent different terminology and handling, but I'm sure folks who don't want to write their own dependency definitions feel otherwise. Also, by no means was I trying to imply that s6-rc should deduce anything. If anything I was saying that, as an SA, being able to take implicit dependencies that mostly exist in the form of polling loops in run scripts and other such hackery (such as my wireless setup) and rewrite them as explicit dependencies for the state manager to manage sounds great and is probably the part of s6-rc that I'm most excited about. > > The s6-rc tool includes switches to print resolved bundles and resolved > dependency graphs. I will make it evolve depending on what is actually > needed. What kind of functionality would you like to see ? > (There is also a library to load the compiled form into memory, so writing > a specific binary dumper shouldn't be too hard.) > Low-surprise interoperability with standard unix tools mostly. Assuming the compiled format isn't human readable, having the functionality to do a human-readable dump to stdout (so people can diff, etc) is totally fine. If we can hit the compiled db directly with the same tools and get meaningful results, than all the better. Cheers! -Colin