From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from tb-mx1.topicbox.com (localhost.local [127.0.0.1]) by tb-mx1.topicbox.com (Postfix) with ESMTP id 730B41E7DFB6 for ; Tue, 30 Jul 2024 18:46:17 -0400 (EDT) (envelope-from gordon.w.ross@gmail.com) Received: from tb-mx1.topicbox.com (localhost [127.0.0.1]) by tb-mx1.topicbox.com (Authentication Milter) with ESMTP id FEFAA6795BB; Tue, 30 Jul 2024 18:46:17 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1722379577; b=pNrSCNQYS/iF2Sl3OeAhafF+U0dDFsmx/ybimHYuJey4Zl+L2r yjPARNbr4cbwihUMU31c3H1vSVLoAlSEUeTlAiwS2korj7ZwA8FSZMLeWTnxZkrB ibO7q/hhJYws7P36TyGX5z/lMb+CN7JIxNhFfO11V4PHseGWN94qfoxm3H6XI1Wp 5SsVNvAoPY5FVI3ezEYgVV+5fATyh/LFi0VM2psz3TuoiBX8opvc+cPb7yPj60xV VDMo7eIUgKxhFLMnTGztR6eAnxaDQ7FQptRIX2KGJM203Ii5H2AzNt4nlgznP0wU HELieH3iaJve3sNn3riTVoTjGmcyIkYOYhwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; s=arcseal; t=1722379577; bh=N0IA01hXrRCAtrEHLL4AV6p0PEPf/StGUhP0SVdZRDs=; b=jNgKBU9vh4VZ 3W7dCV5yMXxwf5gUMbOG7ZDkhNddO9EGKl642+AcGf2dvruTL3/u/8f740DFgblq 0lcYctTvimfnv43k/7d1HsiSkYjbnWFRg0anVML/AhT0sGfLiniQF2SZ1l2S6yqQ infawCFweFzGo3n54shNjIBOicvf7f+Bv5+AdpXG35prUzEFCODO+C9l8rYhjJQ1 e7w4R1wGftY+2yLdYTHig5+XNpPSosxqpdfJAQVQJ28ImnL7vbRZwM4wWbST5EKh tb9IsODn/l+xKBaXV0HanHw6Dmo4M2eKv0F63aPEJblF2GwRjWib06842HE3ED8K cgJ8jG8E+Q== ARC-Authentication-Results: i=1; tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=SWk8782U header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.219.175 (mail-yb1-f175.google.com); spf=pass smtp.mailfrom=gordon.w.ross@gmail.com smtp.helo=mail-yb1-f175.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=QBmWTef+; x-me-sender=none; x-ptr=pass smtp.helo=mail-yb1-f175.google.com policy.ptr=mail-yb1-f175.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=-51 state=0 Authentication-Results: tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=SWk8782U header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.219.175 (mail-yb1-f175.google.com); spf=pass smtp.mailfrom=gordon.w.ross@gmail.com smtp.helo=mail-yb1-f175.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=QBmWTef+; x-me-sender=none; x-ptr=pass smtp.helo=mail-yb1-f175.google.com policy.ptr=mail-yb1-f175.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=-51 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeeftddrjeehgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpegg fhgjhfffkffuvfgtsegrtderredttdejnecuhfhrohhmpefiohhrughonhcutfhoshhsuc eoghhorhguohhnrdifrdhrohhsshesghhmrghilhdrtghomheqnecuggftrfgrthhtvghr nhepleekjeelvdekiedttefhvdfhtdffudehteetvdehheeliefghfejgfefieffkefgne cuffhomhgrihhnpehilhhluhhmohhsrdhorhhgpdhgihhthhhusgdrtghomhdpshhshhgu rdhshhdpphgvthgvrhhtrhhisggslhgvrdgtohdruhhkpdgslhhoghhsphhothdrtghomh dpthhophhitggsohigrdgtohhmnecukfhppedvtdelrdekhedrvdduledrudejheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvtdelrdekhedrvddule drudejhedphhgvlhhopehmrghilhdqhigsuddqfhdujeehrdhgohhoghhlvgdrtghomhdp mhgrihhlfhhrohhmpeeoghhorhguohhnrdifrdhrohhsshesghhmrghilhdrtghomheqpd hnsggprhgtphhtthhopedupdhrtghpthhtohepoeguvghvvghlohhpvghrsehlihhsthhs rdhilhhluhhmohhsrdhorhhgqe X-ME-VSScore: -51 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'gordon.w.ross@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=tb-mx1.topicbox.com; identity=mailfrom; envelope-from="gordon.w.ross@gmail.com"; helo=mail-yb1-f175.google.com; client-ip=209.85.219.175 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx1.topicbox.com (Postfix) with ESMTPS for ; Tue, 30 Jul 2024 18:46:17 -0400 (EDT) (envelope-from gordon.w.ross@gmail.com) Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-e04196b7603so3569485276.0 for ; Tue, 30 Jul 2024 15:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722379576; x=1722984376; darn=lists.illumos.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=N0IA01hXrRCAtrEHLL4AV6p0PEPf/StGUhP0SVdZRDs=; b=SWk8782Ucnf7IUQzeVZqA7z1iC/ReUNsZnYJtJuOc5N7Ka20m1V1/uH9i2GAlWkjzp MJNfZslvQ2cRzbej5ay/NLalja1N+uUu/WgUHL4EAXy30xNjh3HMBtb3KbFP5xVE0uIU ZKWp2XccdjHRMwfVCkCPkGECPBnl88WylaECl9Wyfls7ZKQd5nMjpiYQgnM7HoJprSlp FFo8xA8sJMTrUK+eHMbl0i6eDF8G29ag2K1vGyrd8oFSJUN6TlzlI2oJ/37PY65WUrgU rNkG6VJq7Spdgbkqqi/LTJlVa3UD+CtUAtKd5OjnUk6s1tei47KiW7ECv65oBoC98UdA 33xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722379576; x=1722984376; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N0IA01hXrRCAtrEHLL4AV6p0PEPf/StGUhP0SVdZRDs=; b=QBmWTef+s/Y/mw7dbZa5avsClS0Mg5baMqSt7deLPkTmZ3gs+/dFlGTzYCNXtkT4YV QY/uCtUQqESMo9JAVTY5fXPem0CkgfFDv9Wc0R1Sb/UHf4FjFIX4cAEoSaCsB8xO3V19 1zv2lBaHU/Y/Ih8QllUmQQnGb39+J1tJ1+Avsn1tIo8mfnzIVi7rsA3p5zPaZcXuIJLJ l2QM1Exf6Gj8r+IZQopRtbtEZcx781pmjlh7RRTGtFW8iIqIa55a9bnCkoVyVEOsadyx 96X3VXYuwYQitMpDvNBu7Ti9v75DmTr0Sg4O3YqRLFIIWG90cKDrgfUzlQn0VigSqvhG 9pMA== X-Gm-Message-State: AOJu0YzE4DTgovUEG8Tovk6hWxvvWHdOoZ960RsWugY2Kv2DpqaayByq 19/QoUHIFKSWY8zf6cVghQLLxq+g0J7hKFuBV1Xk2lHqkjeNgM1Jqdmvm0It438h4buk5PlbEAz hzZU4OjENWyG1WXTCq2nL8yXOVYk/FQ== X-Google-Smtp-Source: AGHT+IHFF4A8odcicG+cOSPpb0eiJkJL81avRcKaAumIzNSx113E8IRm62j79Z3cIJtTk3r389sr3G5yN9txMbbt7gw= X-Received: by 2002:a05:6902:2403:b0:e05:fea8:4c77 with SMTP id 3f1490d57ef6-e0b5446970amr12963321276.14.1722379576215; Tue, 30 Jul 2024 15:46:16 -0700 (PDT) MIME-Version: 1.0 References: <3D043DE2-817C-4A22-9BB6-A673FAAFDC58@blackdot.be> In-Reply-To: <3D043DE2-817C-4A22-9BB6-A673FAAFDC58@blackdot.be> From: Gordon Ross Date: Tue, 30 Jul 2024 18:46:05 -0400 Message-ID: Subject: Re: [developer] Review - 15665 svc:/network/loopback exits successfully even if it fails To: illumos-developer Content-Type: multipart/alternative; boundary="000000000000cf14ac061e7ebeff" Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 8b338598-4ec5-11ef-bc4b-e563e25a75f8 --000000000000cf14ac061e7ebeff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Optional dependency does that in SMF, right? On Tue, Jul 30, 2024 at 12:56=E2=80=AFPM Jorge Schrauwen via illumos-develo= per < developer@lists.illumos.org> wrote: > This last reply from Peter made me think of the difference between > requires vs after in systemd speak. > > Although that is probably a lot of work as one would need those feature > and somehow fix all manifests that express a dependancy on loopback. > > Admittedly I sometimes miss a more soft dependancy in smf in general. > > ~ sjorge > > On 26 Jul 2024, at 17:16, Peter Tribble wrote: > > =EF=BB=BF > > > > On Fri, Jul 26, 2024 at 2:50=E2=80=AFPM Andy Fiddaman w= rote: > >> >> On Fri, 26 Jul 2024, Peter Tribble wrote: >> >> > On Fri, Jul 26, 2024 at 9:21?AM Andy Fiddaman >> 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 chan= ge >> 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 tha= t >> 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 i= f >> 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 eve= n >> - 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, bu= t >> if >> > this does get into the gate it will be reverted in Tribblix. >> >> Understood. This definitely warrants further discussion. >> > > As I mentioned in my other reply, it seems that what we're after is some > way to mark > a service as having generated an error without bringing the system down b= y > going > into maintenance. Some sort of degraded mode. > > We have a couple of SMF exit codes that look interesting - > SMF_EXIT_MON_DEGRADE > and SMF_EXIT_MON_OFFLINE, but I'm sure they were never implemented. There= 's > even an issue in this area - https://www.illumos.org/issues/7711 (which > refers back to 8891 > which is another case of something dropping into maintenance breaking the > entire system). > > Interestingly, looking at the ssh method script for S11 > > https://github.com/oracle/solaris-userland/blob/master/components/openssh= /sources/sshd.sh#L132 > you see the following: > > # Put the service into degraded mode in case some of previous > # configuration tasks failed. > # We do not let the service enter maintenance mode, since > # we want to keep the system as much operating as feasible. > # > if [ $ret1 -ne 0 ]; then > smf_method_exit $SMF_EXIT_DEGRADED "hostkey_configuration" \ > "Failed to generate missing host keys." > fi > > So the equivalent of SMF_EXIT_DEGRADED might be what we're looking for? > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > > *illumos * / illumos-developer / see > discussions + participant= s > + delivery option= s > Permalink > > --000000000000cf14ac061e7ebeff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Optional dependency does that in SMF, right?


On Fri, Jul 26, 2024 at 2:50=E2= =80=AFPM Andy Fiddaman <andy@omnios.org> wrote:

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?
> >
> >=C2=A0 =C2=A0 =C2=A015665 svc:/network/loopback exits successfully= even if it fails
> >=C2=A0 =C2=A0 =C2=A0https://www.illumos.org/issues/1566= 5
> >=C2=A0 =C2=A0 =C2=A0https://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<= br> was mostly around the addition of the extra dependency to the service, whic= h
I've removed in this new patch set (that is
https://www.i= llumos.org/issues/15664 which remains open).

> If this service fails, I think the best thing to do is drive on so tha= t 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 creat= ed
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 t= he
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 actua= lly
achieved its goal. Is there some middle ground here.

> I think generally it would be wrong for a single voice to veto any cha= nge,
> which means I would generally be uncomfortable sticking a -1 on it, bu= t if
> this does get into the gate it will be reverted in Tribblix.

Understood. This definitely warrants further discussion.

As I mentioned in my other reply, it seems that what we&#= 39;re after is some way to mark
a service as having generated= an error without bringing the system down by going
into main= tenance. Some sort of degraded mode.

We have a couple of = SMF exit codes that look interesting - SMF_EXIT_MON_DEGRADE
and SMF_EXI= T_MON_OFFLINE, but I'm sure they were never implemented. There's
even an issue in this area - https://www.illumos.org/issues/7711 (wh= ich refers back to 8891
which is another case of something dr= opping into maintenance breaking the entire system).

you see= the following:

# Put the service into degraded mode in case some o= f previous
# configuration tasks failed.
# We do not let the servic= e enter maintenance mode, since
# we want to keep the system as much op= erating as feasible.
#
if [ $ret1 -ne 0 ]; then
smf_method_exi= t $SMF_EXIT_DEGRADED "hostkey_configuration" \
=C2=A0 =C2= =A0"Failed to generate missing host keys."
fi

So the equivalent of SMF_EXIT_DEGRADED might be what we're looking f= or?

--
-Peter Tribble
http://www.petertribble.co.uk/= - http://p= tribble.blogspot.com/
--000000000000cf14ac061e7ebeff--