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. Here's the list of packages providing ifupdown scripts: * avahi-autoipd * avahi-daemon * bind9 * bridge-utils * clamav-freshclam * controlaula * epoptes-client * ethtool * firestarter * gogoc * hostapd * hostap-utils * ifenslave-2.6 * ifmetric * ifupdown-extra * ifupdown-scripts-zg2 * initscripts * isatapd * linux-wlan-ng * lprng * ltsp-server * masqmail * miredo * ntpdate * openntpd * openssh-server * openvpn * postfix * resolvconf * samba * sendmail-base * shorewall-init * slrn * slrnpull * tinc * tipcutils * ucarp * uml-utilities * vde2 * vlan * vzctl * whereami * wide-dhcpv6-client * wireless-tools * wpasupplicant I'd like to ask maintainers to check scripts in their packages, and fix issues they find if there are any. Thanks in advance. - -- WBR, Andrew iQIcBAEBCAAGBQJPTKtrAAoJEOJBhVAE1nf8LScP/2i/efgo/TCTHcb3KMlKWdYO uoagL18Anc822Ub+wT0Veh3rUoym2gC7HlNOu3eNB+Wxdr0kia8fmJcOb58jU+Ey z4xIP0WCnAQB7do+9aT6/q8wHVwGjdLtXdy/PUpUOc6vsxNv2Rad4fB8U+dqFz9W 9pW8QJHntx6rtjHQ3gX00TgNgVdXuYnPpFKjHVCmSGcHWSyqu4ZSFFpNhAL5E0ed s7jOXemYCSluWFVKusLS0sZrB8eCh3Z6SjArT55C7mNGdjk+QERyJ5QQf9QmETcV ER6NtN/QYWWMHkhi15PW/Gt/AbcH2d2RBjUF8fBt3mxJB0k68QXxDwBFijcIefiI cW10Sp4DG7dcrqwbdfqfohzh3dokczvLxPyL2FiONBR0d/JYY6oSYqfi0ily3bww R15mkbJ7+ybk7KtBJfMD2twVwxOwS9cf7cFV2UhJUdLsij7ru1yJI6jS0K9UIogh mH//qxR3Z63vqUGV1/vAuULqAvhZKoYh4HV1znPTC8QvwsYE7Gfbb7ES+vg7/2yp PYSTWeSh2bSj/fygLWQdrvK3BbQZ3Fy60ABnzyg5yUbHGyslTy/sRqsPgW+wEXFv fQ2+5uTkaIba41QwJ9t7elkiav7GfkRyziVIhh6vwJmIQHtW02Y4+G85xJDhVJUL pR+hbLsvwf8mh23uxtr7 =izP3 -----END PGP SIGNATURE-----
Hi Andrew, 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.
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
Hello, 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.
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? 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. 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.
Hello, Probably they should. 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. There was a bug in ifupdown, but scripts must have been written with this behaviour in mind. 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. 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'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.
Hi Andrew, 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 control@bugs.d.o. Then you can use 661591 to track the change you're planning to introduce. It's eg displayed in the bugs webpage. 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 ;-) then please file bugs. and thanks for maintaining ifupdown, cheers! Holger
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 661591@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Steffen Rumberger <inne@sdfeu.org> (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 ftpmaster@debian.org)
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 <inne@sdfeu.org>
Changed-By: Steffen Rumberger <inne@sdfeu.org>
Description:
masqmail - mail transport agent for intermittently connected hosts
Closes: 212852 349211 432793 661591 674666
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
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-----
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
Hello, Obviously, because it wasn't filed against masqmail.
affects 661591 - masqmail thanks [2012-06-23 20:44] Andrew Shadura <bugzilla@tut.by> 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
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.
affects #661591 - ifupdown-scripts-zg2 thanks ifupdown-scripts-zg2 cleanly exits 1 with an error, and exits 0 if everything is fine. Greetings Marc
affects #661591 - ifupdown-scripts-zg2 thanks ifupdown-scripts-zg2 cleanly exits 1 with an error, and exits 0 if everything is fine. Greetings Marc
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
I checked that the ifmetric if-up script exits 0 on success and 1 on error.
I checked that the ifmetric if-up script exits 0 on success and 1 on error.
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
if-(up|down) script in OpenVPN will only return a non-zero exit code on problems.
Sending control line properly, 2 years ago I did not do this correctly. Javier
I believe ethtool's scripts always return 0 if successful. Ben.
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
reassign 661591 whereami thanks The issue is in the script whereami installs; it should check for the presence of the whereami binary, or else exit without an error.
Shorewall's script always returns zero, afaics. J.
affects 661591 - slrn slrnpull thanks Those packages no longer provide ifupdown scripts. Nicolas.