From: Andy Fiddaman <andy@omnios.org>
To: illumos-developer <developer@lists.illumos.org>
Subject: Re: [developer] Review - 15665 svc:/network/loopback exits successfully even if it fails
Date: Fri, 26 Jul 2024 13:50:04 +0000 (UTC) [thread overview]
Message-ID: <e686705a-83f6-44d6-9fc0-68848059db4e@omnios.org> (raw)
In-Reply-To: <CAEgYsbHoTOmhq5_B2_9XhpY07oKBAB1mze4SKFm__utaqmUUnA@mail.gmail.com>
On Fri, 26 Jul 2024, Peter Tribble wrote:
> On Fri, Jul 26, 2024 at 9:21?AM Andy Fiddaman <illumos@fiddaman.net> wrote:
>
> > Please can you review the following change?
> >
> > 15665 svc:/network/loopback exits successfully even if it fails
> > https://www.illumos.org/issues/15665
> > https://code.illumos.org/c/illumos-gate/+/3610
> >
>
> When this first came up I expressed my belief that making this change is
> the wrong
> thing to do, and I'll express it again.
Apologies Peter. I had recalled that your objection to the original change
was mostly around the addition of the extra dependency to the service, which
I've removed in this new patch set (that is
https://www.illumos.org/issues/15664 which remains open).
> If this service fails, I think the best thing to do is drive on so that the
> system can come up as far as possible to maximise the chance that the system
> comes up far enough for an administrator to be able to get in and fix it. Not
> putting the service into maintenance is a feature, not a bug.
The impetus for this change is that over the past couple of years we've had
a number of occasions where we've had to debug networking problems that
have had their root in the fact that the loopback interfaces were not created
for one reason or another. It happened again yesterday in a non-global zone. In
all of these, it would have been really useful and expedited diagnosis if the
service had gone into maintenance. I understand the perspective of allowing the
system to come up as far as possible - to the point of remote access even - but
it still seems wrong for a service to report success where it has not actually
achieved its goal. Is there some middle ground here.
> I think generally it would be wrong for a single voice to veto any change,
> which means I would generally be uncomfortable sticking a -1 on it, but if
> this does get into the gate it will be reverted in Tribblix.
Understood. This definitely warrants further discussion.
Andy
next prev parent reply other threads:[~2024-07-26 13:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 8:20 Andy Fiddaman
2024-07-26 12:44 ` [developer] " Peter Tribble
2024-07-26 13:41 ` Toomas Soome
2024-07-26 14:05 ` Peter Tribble
2024-07-26 13:50 ` Andy Fiddaman [this message]
2024-07-26 15:14 ` Peter Tribble
2024-07-26 15:55 ` Jorge Schrauwen
2024-07-30 22:46 ` Gordon Ross
2024-07-31 9:44 ` Peter Tribble
2024-08-01 8:48 ` Joshua M. Clulow
2024-07-26 18:08 ` Alan Coopersmith
2024-08-07 20:04 ` Andy Fiddaman
2024-09-09 17:36 ` Andy Fiddaman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e686705a-83f6-44d6-9fc0-68848059db4e@omnios.org \
--to=andy@omnios.org \
--cc=developer@lists.illumos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).