Re: First thoughts on s6

From: Colin Booth <cathexis_at_gmail.com>
Date: Wed, 17 Jun 2015 18:44:22 -0700

On Wed, Jun 17, 2015 at 4:32 PM, Avery Payne <avery.p.payne_at_gmail.com> wrote:
>
> With yesterday's mention of the idea of a clearinghouse, the concept that
> daemon options need to be versioned has been in the back of my head. Here
> is an idea: versioned definitions. A crude example:
>
> /etc/sv/sshd/envdir/DAEMON -> /etc/sv/sshd/envdir/current/DAEMON
> /etc/sv/sshd/envdir/DAEMONOPTS -> /etc/sv/sshd/envdir/current/DAEMONOPTS
> /etc/sv/sshd/envdir/current-> /etc/sv/sshd/versions/v3
> /etc/sv/sshd/envdir/versions/v3/DAEMON
> /etc/sv/sshd/envdir/versions/v3/DAEMONOPTS
> /etc/sv/sshd/envdir/versions/v2/DAEMON
> /etc/sv/sshd/envdir/versions/v2/DAEMONOPTS
>
> Settings are now versioned and encapsulated to their definition; old
> definitions can be kept indefinitely, allowing you to support older "legacy"
> installs; you can still pull just one definition of /etc/sv/sshd (and all of
> the files and directories inside of it) out of a tarball, put it in place,
> and everything works; no changes are needed for any run scripts; and if you
> happen to be running an older version (for whatever reason) you can easily
> switch by changing just the "current" file. Distro maintainers and
> packagers will not care that much, because they'll simply point the
> ./current symlink at whatever version their daemon uses and they're off to
> the races.
>
> Drawbacks? File count goes up. Complexity goes up a smidgeon with the
> concept of "current". Storage bloats a bit, it seems like symlinks require
> an entire disk block on ext3/ext4. And yes, the problem of getting timely
> updates for new options still exists. But it's now a write-it-one-time
> thing.
>
Makes sense, though timely updates for options is the thing that I'm
thinking about in terms of the maintenance burdon. The problem as I
see it is that upstream changes, the clearinghouse maintainer needs to
catch that, and then everyone who uses the scripts needs to update
their script repository before they update the service that depends on
it. Better to update your service package and just get the new run
script at the same time. So yeah, it's forwards compatibility that I'm
concerned about, not making sure your run scripts support legacy
versions.
>
> This begs the question - wouldn't the .service files have the corresponding
> daemon flags in them? And if so, wouldn't that also imply that .service
> files would have the same level of upkeep and maintenance as run scripts,
> i.e. with a major version change the parameters change as well, requiring a
> new .service? And wouldn't that also mean that they aren't as "portable" as
> they would sound, because the same versioning problem exists?
>
They totally have the corresponding daemon flags in them, but you'd
assume that when the package maintainer updated the service that they
also would update the definitions file. My argument here isn't that
you wouldn't need to update stuff, my argument is that you spread that
update burdon around to all the maintainers of their individual
packages, instead of relying on a single person or small group of
people to maintain an ancillary package that is critical to all
supervised daemons in the unix world.
>
> To me service units are Ash nazg durbatul√Ľk but that's a personal opinion.
> Those .service files seem fishy to me, when Ted T'so had problems getting
> one running.
>
They aren't that bad, at least the few that I have on my system due to
various daemon installs. To be fair though, I don't think I have
anything with super complicated startups installed.
>
> Agreed. But we have a chicken-and-egg problem; they won't start the process
> of converting to run scripts until someone shows up to "seed" it first.
True. Though every new init will have that problem. At least for the
Debian world I think a svcdir generator that works off of systemd
service definitions would be a pretty reasonable starting point, at
least for the majority of cases. That way it's trivial for package
maintainers to ease their way into making run scripts for process
supervisors, and make it easy for people who want to get into
supervision to not need to do a whole chunk of legwork up front.

Cheers!


-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake
Received on Thu Jun 18 2015 - 01:44:22 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC