On 6/25/2015 2:28 PM, post-sysv wrote:
I'm honestly struggling to think of a practical use case for this,
though I may be lacking sufficient context.
It actually does have a use case, as I've run into it. (more on this in
a moment)
The case of a daemon breaking semantics of existing options is quite
seldom seen, and just a bad practice for reasons of maintaining least
surprise and compatibility. Even when major versions are bumped, it's
rare to see such a thing.
Try some of the settings as demonstrated on the samples for runit. Many
of them will no longer work with the supplied flags because:
1. the option has changed meaning
2. the option has changed its designation, i.e. what was -a is now -b
3. the option was removed entirely
All of these issues persist in those definitions. While the majority of
the run scripts published are reasonably well written, they continue to
"bake in" the settings for "that place and time", which means the above
3 issues will sooner or later bite your hind-end when you aren't looking.
Now when new options are added, old configurations still tend to run
the same (unless it's a scenario of this flag now needs that flag set
in unison, which again is a breaking change).
This *used* to be the case, but with some of the things you see with
RHEL and others, things tend to rev to the next version "to resolve an
issue", regardless if reving will break the settings for that daemon. I
know this is a less than wonderful approach, but it is what it is, it is
definitely coming from a commercial entity that provides this as a
service to customers, and customers may or may not even care, all they
know is that the upgrade/update broke something and they need to futz
with it.
The proposal would do away with that. With each update, you would be
able to push out the "correct" settings and it would be up to the admin
to ensure a smooth transition.
By all means just version and update the runscript. Symlink farms are
always frustrating to deal with. It didn't work well for sysvinit at all.
With regard to symlink use, I think that SysV rc stuff had a problem
with the creation and destruction of various links in various locations
as services were sequenced, added, and removed, not to metion the entire
start vs kill set of scripts. Symlinks are fine when they are well
managed, and I think in my not very humble and very uneducated opinion
that SysV rc scripts were (and still are) not well managed. I can only
say that from having to fight with them for the last 5+ years to get
them to do what I want, so I am no expert on their use, I only claim
some experience.
Compare:
* there are symlinks created in /service, which are a given for most of
the supervision frameworks, so it's not like we aren't using this approach.
* supervision-scripts uses symlinks for all of the run script
definitions, but you never have to move or change them. You only change
the one link, located at a known location.
* The proposal would add one more symlink per definition total.
In this case, I'm asking for one additional symlink per definition,
total. The name and position of the link will be fixed and it only
changes when you change what it points at. There is no dynamic creation
or desctruction, there is no need for sequencing, there is no need for
context embedded in the file name - all of which made the SysV approach
a headache.
Just playing Devil's Advocate here...
