Great, your point I wanted to hear especially.
But, well, I am disillusioned with my hops for s6.
My fault about SIGPWR, RTMIN+3 should be used instead, please, treat
SIGPWR as a template for any other signal name, that doesn't matter.
Not only me who want this "lxd simplicity", e.g.
https://github.com/skarnet/s6/issues/5, where you fully described your
position.
Just as a thought: You have implemented signal diversion, but limited to
known signals. Why not just pass unknown signals as numbers or something
like (S6SIG55011), so they can be diverted by user? You wouldn't have to
catalogue them.
We need good, flexible and user-friendly init alternatives for linux
(other systems have their own).
So, I just want to make user experience of new runit or s6 users who use
LXD more comfortable, apologies if this hurts someone.
Have a good day!
On 14.02.2020 21:30, Laurent Bercot wrote:
>> 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 Mon Feb 17 2020 - 10:00:12 UTC