Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Dimitris Aragiorgis]

Hi,

I bumped into this issue as well. Upgrading from jessie to strech the
networking service that calls `ifup -a` fails because the interface is
already configured.

I think this commit is to blame:

https://salsa.debian.org/debian/ifupdown/commit/87ca29628d452d7eaa124a943ffb2382743f19e0

What if you have an initramfs script that configures the interface,
e.g., during iSCSI boot? In our case an initramfs script, brings up the
interfaces and does udhcpc to eventually obtain boot critical metadata
from a metadata server, i.e., necessary for iSCSI discovery.

Does ifupdown really require that an interface is down to be able to
function properly? This seems to be severely limiting. Trying out
things, I see that it "works" if the interface is set to inet dhcp, but
this seems to be a random but fortunate side-effect of dhclient handling
and suppressing the RTNETLINK answers: File exists error.

Should somehow the networking.service systemd unit change, or is this
supposed to be an ifupdown bug?

Thanks,
dimara

On Wed, 13 Dec 2017 21:25:55 +0100 Ralf Jung  wrote:
> Hi,
> 
> >> The relevant bits of the /etc/network/interfaces.d/* looks as follows:
> > [...]
> >> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 
> >> 185.X.X.X ttl 255
> > [...]
> > 
> > The problem with jessie was that it ignored any errors from
> > pre/post-up/down commands. This was fixed in stretch. If you want
> > ifupdown to ignore any errors from your pre-up command, just append "||
> > true" to it, like:
> > 
> >  pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 
> > 185.X.X.X ttl 255 || true
> > 
> > However, this begs the question: why does this fail at all?
> 
> Actually, I am wondering even more why it tries to execute this again
> even though the interface is already up.
> 
> > I tried the
> > exact same iface stanza on a stretch machine, and doing repeated ifup and
> > ifdowns just works as it should.
> 
> ifup should be idempotent, right?  Did you try "ifup && ifup"?
> 
> We also have another stretch machine on which this works.  So I am a bit
> lost about why on one machine, "ifup" tries to bring up an already up
> interface.
> 
> >> add tunnel "gre0" failed: File exists
> > 
> > I don't know why it prints "gre0" here, I think that's a bug in ip.
> 
> I see the same behavior.
> 
> > I do
> > see it when I manually try to do the ip tunnel add command multiple
> > times without ip tunnel del inbetween.
> > 
> >> With exactly the same setup (literally -- this is all automatically 
> >> deployed), I
> >> do not get any errors on our jessie systems.  Also the stretch system with 
> >> a
> >> slightly older kernel (4.9.0-3) is not affected.  The broken machine has
> >> 4.9.0-4-amd64.
> > 
> > Hm, that is also weird. Maybe there is something that causes this tunnel
> > to be brought up before ifup tries to do the same?
> 
> Does ifup have state?  So, could it be that on one machine it up'ed the
> tunnel successfully and that's why it dos not try again, because it
> remembers it already did that?
> I thought it does not have any state beyond just the kernel network stack.
> 
> ; Ralf
> 
> 


signature.asc
Description: Digital signature

Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Ralf Jung]

Hi,

>> The relevant bits of the /etc/network/interfaces.d/* looks as follows:
> [...]
>> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
>> ttl 255
> [...]
> 
> The problem with jessie was that it ignored any errors from
> pre/post-up/down commands. This was fixed in stretch. If you want
> ifupdown to ignore any errors from your pre-up command, just append "||
> true" to it, like:
> 
>  pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
> ttl 255 || true
> 
> However, this begs the question: why does this fail at all?

Actually, I am wondering even more why it tries to execute this again
even though the interface is already up.

> I tried the
> exact same iface stanza on a stretch machine, and doing repeated ifup and
> ifdowns just works as it should.

ifup should be idempotent, right?  Did you try "ifup && ifup"?

We also have another stretch machine on which this works.  So I am a bit
lost about why on one machine, "ifup" tries to bring up an already up
interface.

>> add tunnel "gre0" failed: File exists
> 
> I don't know why it prints "gre0" here, I think that's a bug in ip.

I see the same behavior.

> I do
> see it when I manually try to do the ip tunnel add command multiple
> times without ip tunnel del inbetween.
> 
>> With exactly the same setup (literally -- this is all automatically 
>> deployed), I
>> do not get any errors on our jessie systems.  Also the stretch system with a
>> slightly older kernel (4.9.0-3) is not affected.  The broken machine has
>> 4.9.0-4-amd64.
> 
> Hm, that is also weird. Maybe there is something that causes this tunnel
> to be brought up before ifup tries to do the same?

Does ifup have state?  So, could it be that on one machine it up'ed the
tunnel successfully and that's why it dos not try again, because it
remembers it already did that?
I thought it does not have any state beyond just the kernel network stack.

; Ralf

Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Guus Sliepen]

On Sun, Nov 26, 2017 at 06:09:29PM +0100, Ralf Jung wrote:

> The following command:
> 
>   /sbin/ifup -a --read-environment
> 
> tries to bring up some GRE tunnels on my system that are already up.  
> Obviously,
> this fails.  One consequence of that is that the systemd "networking" unit is
> always marked as failed, so systemd never thinks the network is actually up.
> 
> The relevant bits of the /etc/network/interfaces.d/* looks as follows:
[...]
> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
> ttl 255
[...]

The problem with jessie was that it ignored any errors from
pre/post-up/down commands. This was fixed in stretch. If you want
ifupdown to ignore any errors from your pre-up command, just append "||
true" to it, like:

 pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
ttl 255 || true

However, this begs the question: why does this fail at all? I tried the
exact same iface stanza on a stretch machine, and doing repeated ifup and
ifdowns just works as it should.

> add tunnel "gre0" failed: File exists

I don't know why it prints "gre0" here, I think that's a bug in ip. I do
see it when I manually try to do the ip tunnel add command multiple
times without ip tunnel del inbetween.

> With exactly the same setup (literally -- this is all automatically 
> deployed), I
> do not get any errors on our jessie systems.  Also the stretch system with a
> slightly older kernel (4.9.0-3) is not affected.  The broken machine has
> 4.9.0-4-amd64.

Hm, that is also weird. Maybe there is something that causes this tunnel
to be brought up before ifup tries to do the same?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Ralf Jung]

Package: ifupdown
Version: 0.8.19
Severity: normal

Dear Maintainer,

The following command:

  /sbin/ifup -a --read-environment

tries to bring up some GRE tunnels on my system that are already up.  Obviously,
this fails.  One consequence of that is that the systemd "networking" unit is
always marked as failed, so systemd never thinks the network is actually up.

The relevant bits of the /etc/network/interfaces.d/* looks as follows:

auto tun-up-b_ak
iface tun-up-b_ak inet static
address 100.64.5.59
netmask 255.255.255.254
pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
ttl 255
post-up ip link set $IFACE mtu 1280
post-down ip tunnel del $IFACE


iface tun-up-b_ak inet6 static
address 2a03:2260:0:ba::2/64
netmask 64

ifup itself shows the following:

$ sudo /sbin/ifup -a --read-environment -v
ifup: parsing file /etc/network/interfaces.d/ffrl_gre
ifup: parsing file /etc/network/interfaces.d/ffrl_gre~
ifup: parsing file /etc/network/interfaces.d/freifunk
ifup: parsing file /etc/network/interfaces.d/general
ifup: parsing file /etc/network/interfaces.d/inter_gw
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool

ifup: configuring interface tun-up-b_ak=tun-up-b_ak (inet)
ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X ttl 255
add tunnel "gre0" failed: File exists
ifup: failed to bring up tun-up-b_ak

/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/upstart

With exactly the same setup (literally -- this is all automatically deployed), I
do not get any errors on our jessie systems.  Also the stretch system with a
slightly older kernel (4.9.0-3) is not affected.  The broken machine has
4.9.0-4-amd64.

Kind regards,
Ralf