Hi Andrew,
On Tue, Feb 28, 2012 at 11:24:43AM +0100, Andrew O. Shadura wrote:
> Starting with the last beta, ifupdown calls run-parts for if-*.d scripts
> with --exit-on-error, so if the script fails, interface isn't marked as
> configured (see #547587).
> However, it's been reported that some scripts return wrong exit codes
> sometimes, causing failure during network configuration.
My doubt here is: what is the definition of a *right* exit code now, from
ifupdown's POV? When is it appropriate for a hook which has failed to exit
non-zero?
This is a pretty significant change in behavior from the perspective of the
packages providing hooks, as it means that they now have to avoid giving
meaningful exit codes in order to not cause ifupdown to fail to run
subsequent hooks. OTOH, there might be cases where that's beneficial
because it lets a critical hook declare that an interface bring-up hasn't
succeeded and the interface bring-up should be rolled back so the admin can
try again. But how do we define "critical" hooks?
I would appreciate seeing some more guidance here for hook maintainers. As
you may be aware, Ubuntu is using ifupdown 0.7beta2 for its next release,
and has had to revert this particular behavior change because it made
networking significantly more brittle.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/[email protected][email protected]
Subject: Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Date: Tue, 28 Feb 2012 22:37:29 +0100
reassign 661591 ifupdown
thanks
Hi,
just from what I've read in those two replies to this bug yet, I think I agree
that this change should be reverted.
And if you really want/need/do this change which needs changes in 30 (or so)
other packages, then please file 30 bugs against those package and then use
these bugs as blockers against one bug for tracking. (And I'd prefer this bug
to be one against ifupdown and not general, but YMMV.)
But, definitly, filing a bug against general saying these and these package
need to be fixed wont do it.
cheers,
Holger
Acknowledgement sent
to Andrew Shadura <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Tue, 28 Feb 2012 21:57:09 GMT) (full text, mbox, link).
Hello,
On Tue, 28 Feb 2012 22:37:29 +0100
Holger Levsen <[email protected]> wrote:
> just from what I've read in those two replies to this bug yet, I
> think I agree that this change should be reverted.
> And if you really want/need/do this change which needs changes in 30
> (or so) other packages, then please file 30 bugs against those
> package and then use these bugs as blockers against one bug for
> tracking. (And I'd prefer this bug to be one against ifupdown and not
> general, but YMMV.) But, definitly, filing a bug against general
> saying these and these package need to be fixed wont do it.
It does NOT involve all of those packages directly. Most of them do
things correctly, some don't. That's why I've asked all the maintainers
to do checks needed, just to make it easier, so people review their
packages only and don't go into deep of others' packages.
--
WBR, Andrew
Acknowledgement sent
to Steve Langasek <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Tue, 28 Feb 2012 22:30:03 GMT) (full text, mbox, link).
On Tue, Feb 28, 2012 at 09:09:22PM +0100, Andrew Shadura wrote:
> On Tue, 28 Feb 2012 11:27:37 -0800
> Steve Langasek <[email protected]> wrote:
> > > However, it's been reported that some scripts return wrong exit
> > > codes sometimes, causing failure during network configuration.
> > My doubt here is: what is the definition of a *right* exit code now,
> > from ifupdown's POV? When is it appropriate for a hook which has
> > failed to exit non-zero?
> When failure to execute a hook leads to interface being non-operational.
Yes, that's probably a reasonable threshold. What should packages like
miredo and wide-dhcpv6-client do? Both of these hooks have to do with
routing information; if an interface comes up but the hook fails, the
interface may be operational but not actually routing traffic to the
networks the user cares about reaching. Should these hooks exit non-zero on
failure, or not?
Could this guidance be included in the ifupdown documentation as a clue to
maintainers?
> > This is a pretty significant change in behavior from the perspective
> > of the packages providing hooks, as it means that they now have to
> > avoid giving meaningful exit codes in order to not cause ifupdown to
> > fail to run subsequent hooks. OTOH, there might be cases where
> > that's beneficial because it lets a critical hook declare that an
> > interface bring-up hasn't succeeded and the interface bring-up should
> > be rolled back so the admin can try again. But how do we define
> > "critical" hooks?
> This isn't a change in behaviour at all.
Er, it most certainly is. You may argue that the previous behavior was
*wrong*, but it's just plain false to say that the behavior isn't changing.
And the change is incompatible with at least some existing hook scripts,
which means it's incumbent on you as the ifupdown maintainer to coordinate
this behavior change with the maintainers of those other packages. *Not*
just filing a bug on "general", but actually following through on this
transition to make sure things get fixed as needed.
On Tue, Feb 28, 2012 at 10:54:38PM +0100, Andrew Shadura wrote:
> > And if you really want/need/do this change which needs changes in 30
> > (or so) other packages, then please file 30 bugs against those
> > package and then use these bugs as blockers against one bug for
> > tracking. (And I'd prefer this bug to be one against ifupdown and not
> > general, but YMMV.) But, definitly, filing a bug against general
> > saying these and these package need to be fixed wont do it.
> It does NOT involve all of those packages directly. Most of them do
> things correctly, some don't. That's why I've asked all the maintainers
> to do checks needed, just to make it easier, so people review their
> packages only and don't go into deep of others' packages.
A bug filed against "general" is not an appropriate means of notifying
package maintainers of anything at all. "general" bugs are sent to
debian-devel, which maintainers are not required to follow.
I think Holger is right that this needs to be done as a mass bug filing or
other coordinated effort to review all of the hooks.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/[email protected][email protected]
Acknowledgement sent
to Andrew Shadura <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Tue, 28 Feb 2012 22:48:03 GMT) (full text, mbox, link).
Hello,
On Tue, 28 Feb 2012 14:27:15 -0800
Steve Langasek <[email protected]> wrote:
> > When failure to execute a hook leads to interface being
> > non-operational.
> Yes, that's probably a reasonable threshold. What should packages
> like miredo and wide-dhcpv6-client do? Both of these hooks have to
> do with routing information; if an interface comes up but the hook
> fails, the interface may be operational but not actually routing
> traffic to the networks the user cares about reaching. Should these
> hooks exit non-zero on failure, or not?
Probably they should.
> Could this guidance be included in the ifupdown documentation as a
> clue to maintainers?
The problem is that it's entirely up to the maintainer of an
appropriate package; ifupdown doesn't really care what the hook script
is doing, so it's script maintainer who should decide if this
particular failure can be ignored (probably, with a warning) or if it's
critical.
> > This isn't a change in behaviour at all.
> Er, it most certainly is. You may argue that the previous behavior
> was *wrong*, but it's just plain false to say that the behavior isn't
> changing.
There was a bug in ifupdown, but scripts must have been written with
this behaviour in mind.
> And the change is incompatible with at least some existing hook
> scripts, which means it's incumbent on you as the ifupdown maintainer
> to coordinate this behavior change with the maintainers of those
> other packages. *Not* just filing a bug on "general", but actually
> following through on this transition to make sure things get fixed as
> needed.
Obviously I want this process to happen, but as a start a bug must be
filed, so discussion can start, no? I understand this exactly this way.
> > It does NOT involve all of those packages directly. Most of them do
> > things correctly, some don't. That's why I've asked all the
> > maintainers to do checks needed, just to make it easier, so people
> > review their packages only and don't go into deep of others'
> > packages.
> A bug filed against "general" is not an appropriate means of notifying
> package maintainers of anything at all. "general" bugs are sent to
> debian-devel, which maintainers are not required to follow.
The idea was to make an announcement and to have some kind of a central
point where the status can be seen. Also, I don't feel it a good idea
to file bugs against packages not having them, and I can't physically
check all the packages on my own to decide if they have bugs or not.
Debian-devel seems to be the best place for this, I think.
> I think Holger is right that this needs to be done as a mass bug
> filing or other coordinated effort to review all of the hooks.
I'm open to suggestions how to perform this better; I tried to review
the packages from that list, but it's no easy task for me as I do not
maintain any of them, so I can easily miss some important detail.
That's why I asked for help here. Also, I wasn't going to push that
particular change until I'm sure that at least the most of the packages
don't have any problems with this.
--
WBR, Andrew
Acknowledgement sent
to Holger Levsen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Tue, 28 Feb 2012 23:09:11 GMT) (full text, mbox, link).
Subject: Re: Bug#661591: packages providing ifupdown scripts must have those scripts fixed if needed
Date: Wed, 29 Feb 2012 00:04:24 +0100
Hi Andrew,
On Dienstag, 28. Februar 2012, Andrew Shadura wrote:
> Obviously I want this process to happen, but as a start a bug must be
> filed, so discussion can start, no? I understand this exactly this way.
Yes, use this bug to track all the other bugs you (and others) will be filing.
then use
block 661591 by 123456
and send this to [email protected].
Then you can use 661591 to track the change you're planning to introduce. It's
eg displayed in the bugs webpage.
> point where the status can be seen. Also, I don't feel it a good idea
> to file bugs against packages not having them, and I can't physically
> check all the packages on my own to decide if they have bugs or not.
I dont understand what you mean you cannot check 30 packages (or how many were
on your initial list? not much more, iirc) on your own physically. Sounds like
3h work or such, maybe 6h. Or 9h. But surely something you can do ;-)
On Dienstag, 28. Februar 2012, Andrew Shadura wrote:
> but rather a number of bugs in some of the packages in the list.
then please file bugs.
and thanks for maintaining ifupdown,
cheers!
Holger
Source: masqmail
Source-Version: 0.3.4-1
We believe that the bug you reported is fixed in the latest version of
masqmail, which is due to be installed in the Debian FTP archive:
masqmail_0.3.4-1.debian.tar.gz
to main/m/masqmail/masqmail_0.3.4-1.debian.tar.gz
masqmail_0.3.4-1.dsc
to main/m/masqmail/masqmail_0.3.4-1.dsc
masqmail_0.3.4-1_amd64.deb
to main/m/masqmail/masqmail_0.3.4-1_amd64.deb
masqmail_0.3.4.orig.tar.gz
to main/m/masqmail/masqmail_0.3.4.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Steffen Rumberger <[email protected]> (supplier of updated masqmail package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 27 May 2012 14:30:42 +0200
Source: masqmail
Binary: masqmail
Architecture: source amd64
Version: 0.3.4-1
Distribution: unstable
Urgency: low
Maintainer: Steffen Rumberger <[email protected]>
Changed-By: Steffen Rumberger <[email protected]>
Description:
masqmail - mail transport agent for intermittently connected hosts
Closes: 212852349211432793661591674666
Changes:
masqmail (0.3.4-1) unstable; urgency=low
.
* New upstream release. (Closes: #349211)
* New Maintainer: Steffen Rumberger maintains the package now with
the help of Markus Schnalke.
* New init-script based on skeleton.
- Also converted to lsb fancy boot messages. (Closes: #674666)
* Switch to source format 3.0 (quilt) and Debhelper compatibility
level 9.
* Set Standards-Version to 3.9.3
* No more use of Debconf for the configuration. The new upstream
version makes a minimal static configuration file possible.
* Fixed removal of user-created data on package purge.
* Ifupdown hooks are not installed by default anymore. (Closes:
#212852, #661591)
* Stop handling inetd. The MTA can assume to have the SMTP port
reserved for it. (Closes: #432793)
Checksums-Sha1:
9565f7b3c674c589117cafa0b124aa7ce6381c8a 1976 masqmail_0.3.4-1.dsc
2509f14704626d74481a826a0dda21cc3742dca8 255824 masqmail_0.3.4.orig.tar.gz
c47ef44f2f62ffc973b09fb6a3bee938ef9dfbe4 18959 masqmail_0.3.4-1.debian.tar.gz
562764bffd5f19048d44fa1fa1e6c2b91ecd96d0 141612 masqmail_0.3.4-1_amd64.deb
Checksums-Sha256:
e6db2dbd9b83bc7079557ad8d80678771f04317e09050f06d7dc8518e48355a6 1976 masqmail_0.3.4-1.dsc
1f0db635febc4fa8336a0645f444faf26c9db346d5056f9367206265c83cc06c 255824 masqmail_0.3.4.orig.tar.gz
ada19c3c500f52d77bafe44dd223f185ec7685ca8d6705a63bc442f05dee6ee0 18959 masqmail_0.3.4-1.debian.tar.gz
9251469bb6933be5aec6ee897c12590fa5de73860a72b5533b5f6660246dd0d2 141612 masqmail_0.3.4-1_amd64.deb
Files:
f8fa2bcd042b62f03efeb9f7a41d8113 1976 mail extra masqmail_0.3.4-1.dsc
551bd887c71d7b8f3bb149b617adb1b3 255824 mail extra masqmail_0.3.4.orig.tar.gz
2f503233b8845ed50b50cd567ac6f666 18959 mail extra masqmail_0.3.4-1.debian.tar.gz
162c14341e6d37c57cb7a60b04c18dee 141612 mail extra masqmail_0.3.4-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCgAGBQJP4KuwAAoJEOCD7BUSMcRl3eYP/15DJNzsVf5m/RqcAWOAH7eP
QIcGiWZMoy1EbYfWWoE7WHsn80BvDjC/X36daOo9mGjRdO28z0mg0+DzlKFrVr/Q
tN1MGyL/P5Qadf1rdGAXAZa+Hcb0JnWbvwOCJGl4026hm0joAHUX+LpMcrUDprYm
rNJAAam9aArW/mpoylw/54xwol1YG8Wwg1eLaipJCJgjbmPNcIwKNbynJXuuumyB
eppHa5mcnRnnI1NBf1I+qHXFi++mfHgc6460JvvGCwRrf2Z89ReQalyZLKJsAvT8
nx0SQmPL36Ly7FSnsVRmU9591sXQn/IAMeNN08LMRWr290+ffFIWnvh8KF7eYRRT
+XG9NHoI9If5YrWtpEXn+D8QXG+lViZNqH1ZSA6N4ns29MhvI2nvB9W/3VDCcHHs
m9Ag0gNUdpv8flXd1gWQIwyWN1d5TqLy4oh5y7YAhKnu0CbDsSCHtwePK8P2upNk
7ubJiOBOZMCxCDizR5QhuqFD6KhKbXQOT5UGXbJzC25X2eWd+njqvQJZDIGvEa4A
Tr3+WpX6WeKIgWHCqc9u8CVzb0EnFtdsdd19UcywQ1b6NzvsGD61zMhG9FfqOll6
85FU1/cUe4UrSyOag+ZN0NXRI+jGEGBGS8/0M7N3g2nC7GSLPWqnejiN2YwBjN1c
m5co5wp+pn57WEq/OXUp
=aQgg
-----END PGP SIGNATURE-----
Acknowledgement sent
to markus schnalke <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Sat, 23 Jun 2012 10:54:16 GMT) (full text, mbox, link).
Subject: Bug #661591: packages providing ifupdown scripts must have
those scripts fixed if needed
Date: Sat, 23 Jun 2012 12:30:09 +0200
Andrew,
why do you think bug #661591 is not fixed?
Was it this missleading changelog message:
Ifupdown hooks are not installed by default anymore.
Or do you have other reasons?
Masqmail-0.3.4-1 doesn't install ifupdown hooks at all. Actually, it
does not at all interface ifupdown anymore.
Is there any reason why this bug should not be considered fixed?
meillo
Acknowledgement sent
to Andrew Shadura <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Sat, 23 Jun 2012 18:48:03 GMT) (full text, mbox, link).
Hello,
On Sat, 23 Jun 2012 12:30:09 +0200
markus schnalke <[email protected]> wrote:
> Or do you have other reasons?
Obviously, because it wasn't filed against masqmail.
--
WBR, Andrew
Acknowledgement sent
to markus schnalke <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Sat, 23 Jun 2012 20:03:06 GMT) (full text, mbox, link).
Subject: Re: Bug #661591: packages providing ifupdown scripts must have those scripts fixed if needed
Date: Sat, 23 Jun 2012 21:58:38 +0200
affects 661591 - masqmail
thanks
[2012-06-23 20:44] Andrew Shadura <[email protected]>
> On Sat, 23 Jun 2012 12:30:09 +0200
> markus schnalke <[email protected]> wrote:
>
> > Or do you have other reasons?
>
> Obviously, because it wasn't filed against masqmail.
Oh, now I see. Seems as if I am not enough used to the Debian BTS.
I'll only remove masqmail from being affected by the bug.
Sorry for the inconvenience.
meillo
Acknowledgement sent
to Guus Sliepen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Mon, 25 Jun 2012 18:45:06 GMT) (full text, mbox, link).
affects 661591 - tinc
thanks
I made a minor change in 1.0.19-1 to ignore errors when poking tinc in response
to other interfaces being brought up. Other than that, I cannot see anything
wrong.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
Acknowledgement sent
to Marc Haber <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew O. Shadura <[email protected]>.
(Wed, 27 Jun 2012 19:36:03 GMT) (full text, mbox, link).
Hi
I have checked vzctl and I can not see that it would do something
wrong. However I agree with that it is hard to tell what a
"right exit code" is when there is no definition.
Best regards,
// Ola
--
--- Inguza Technology AB --- MSc in Information Technology ----
/ [email protected] Annebergsslingan 37 \
| [email protected] 654 65 KARLSTAD |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Acknowledgement sent
to Michael Shuler <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew Shadura <[email protected]>.
(Thu, 05 Sep 2013 23:00:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Javier Fernández-Sanguino Peña <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew Shadura <[email protected]>.
(Wed, 25 Sep 2013 16:51:04 GMT) (full text, mbox, link).
Control: affects 661591 - ifmetric
I have reviewed the ifupdown-extra scripts and they exit with 0 for success
and 1 on error.
The exit on error is only done on some specific cases (when the user has
asked it this way) so the scripts should not have any issues with ifupdown
now using run-parts.
Regards
Javier
Acknowledgement sent
to Ola Lundqvist <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew Shadura <[email protected]>.
(Mon, 06 Oct 2014 19:45:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Alberto Gonzalez Iniesta <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew Shadura <[email protected]>.
(Wed, 29 Oct 2014 17:12:04 GMT) (full text, mbox, link).
Information stored
: Bug#661591; Package ifupdown.
(Fri, 05 Feb 2016 22:57:11 GMT) (full text, mbox, link).
Acknowledgement sent
to Javier Fernández-Sanguino Peña <[email protected]>:
Extra info received and filed, but not forwarded.
(Fri, 05 Feb 2016 22:57:12 GMT) (full text, mbox, link).
Acknowledgement sent
to Ben Hutchings <[email protected]>:
Extra info received and forwarded to list. Copy sent to Guus Sliepen <[email protected]>.
(Wed, 30 Aug 2017 13:12:03 GMT) (full text, mbox, link).
Control: affects -1 - ethtool
I believe ethtool's scripts always return 0 if successful.
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names
taken.
Acknowledgement sent
to "Mark A. Hershberger" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Guus Sliepen <[email protected]>.
(Fri, 19 Apr 2019 19:45:02 GMT) (full text, mbox, link).
Just found that systemd thought networking.service was having trouble on my machine.
When I checked "journalctl -xe" I found the following:
ifup[18149]: run-parts: /etc/network/if-pre-up.d/whereami exited with return code 1
ifup[18149]: ifup: pre-up script failed
systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Acknowledgement sent
to Guus Sliepen <[email protected]>:
Extra info received and forwarded to list.
(Fri, 19 Apr 2019 22:21:03 GMT) (full text, mbox, link).
reassign 661591 whereami
thanks
On Fri, Apr 19, 2019 at 12:35:39PM -0700, Mark A. Hershberger wrote:
> Just found that systemd thought networking.service was having trouble on my machine.
>
> When I checked "journalctl -xe" I found the following:
>
> ifup[18149]: run-parts: /etc/network/if-pre-up.d/whereami exited with return code 1
> ifup[18149]: ifup: pre-up script failed
> systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
The issue is in the script whereami installs; it should check for the
presence of the whereami binary, or else exit without an error.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
Acknowledgement sent
to Jeremy Sowden <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrew McMillan <[email protected]>.
(Fri, 20 Jan 2023 22:57:03 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.