>You mean that adding few lines of code in one place is worse than many
>users of many distros must configure their containers?
>I can configure that myself, but I don't want every user of runit driven
>container to walk this path. Is it necessary?
As counterintuitive as it may seem at first glance, the answers to your
questions are yes and yes. Patching software is always more complex than
configuring it.
Configuring software is using an API that has been especially thought
out to accommodate the needs of various users; if a piece of software
does what you want but requires you to tweak a configuration lever,
then it does what you want period. Because your needing to tweak the
configuration lever is *the exact reason why that lever is there*.
If you refuse to use it, you are basically putting your needs in
front of everyone else's, and demanding that the author of the software
adapt to you at the exclusion of others, instead of using the mechanism
that has been prepared for you.
Patching software:
- requires communication with upstream, so, takes support resources
- requires new deployment, which is significant effort
- is dangerous: it may introduce bugs that you haven't thought of
- may change the workflow of other users
It is, of course, a supplementary order of magnitude more difficult with
software that has no well-defined upstream, as is the case with runit
these days.
But even if your containers were using s6, which has a well-defined
upstream (me) and which does not understand SIGPWR either, I would not
apply your patch suggestion. Why? Because SIGPWR is not standardized,
and s6 aims to be portable, it works ootb on other systems than Linux
and making it use SIGPWR would endanger that. It's the exact kind of
problems you haven't thought of but run into when you want to patch
software, and makes patching always more complex than it seems from the
outside.
Explaining to users how to configure lxc to send the correct signal
to the init system running in the container is a matter of one line in
the documentation. It's extremely manageable.
>Also there is a huge lack of documentation about it on the net,
>especially on signals that runit accepts.
You are talking about patching the code, and you're not going to
look at runit's code to see what signals it accepts? ;)
>It adds complexity to users, and that means users will choose other
>distros which just work.
If your definition of "just working" is "everything is working with
the default configuration", then I don't think you'll find a single
Linux distribution that "just works".
Your runit distro is working just as well as any other. You just
need to set one variable in the lxc configuration. It's certainly not
the only variable you need to set; it's certainly not even the only
variable you need to set conditionally depending on the guest distro.
So, there's really no reason to get hung up on this.
>>>Why can't we be just a little bit more friendly to each other?
Most participants in this thread would benefit from taking this advice
to heart. And in your case, the friendliness will consist in using
the configuration levers that were made for you instead of demanding
that upstream change its defaults to adapt to you.
--
Laurent
Received on Fri Feb 14 2020 - 18:30:47 UTC