On Wed, Jun 17, 2015 at 4:32 PM, Avery Payne <[email protected]> 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
