ubuntu-fan causes issues during network configuration

[Zygmunt Krynicki]

it seems that ubuntu-fan is causing issues with network configuration.

On 16.04 daily image:

root@localhost:~# snappy list
Name Date Version Developer
canonical-pi2 2016-02-02 3.0 canonical
canonical-pi2-linux 2016-02-03 4.3.0-1006-3 canonical
ubuntu-core 2016-02-22 16.04.0-10.armhf canonical

I see this when I'm activating a wifi card on a raspberry pi 2.

root@localhost:~# ifdown wlan0
ifdown: interface wlan0 not configured
root@localhost:~# ifup wlan0
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/c4:e9:84:17:31:9b
Sending on LPF/wlan0/c4:e9:84:17:31:9b
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3 (xid=0x81c0c95e)
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 (xid=0x81c0c95e)
DHCPREQUEST of 192.168.0.170 on wlan0 to 255.255.255.255 port 67 (xid=0x5ec9c081)
DHCPOFFER of 192.168.0.170 from 192.168.0.251
DHCPACK of 192.168.0.170 from 192.168.0.251
RTNETLINK answers: File exists
bound to 192.168.0.170 -- renewal in 17145 seconds.
run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1
Failed to bring up wlan0.

===
[Impact]

Installing ubuntu-fan can trigger error messages when initialising with no fan configuration.

[Test Case]

As above.

[Regression Potential]

Low, suppresses errorneous error messages.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Windelen (ubuntu-fam-windelen)]

Is there a workaround?

It is anoying while working with vlans and changing networks.

[Oliver Grawert (ogra)]

this looks like wlan0 was brought up just fine
seems to mostly be a cosmetic issue that /etc/network/if-up.d/ubuntu-fan doesnt exit quietly

[Paul Schyska (v-paul-w)]

This is breaking cloud-init on AWS for us with 16.04 hvm:ebs-ssd (ami-7a138709).

The networking.service unit goes into failed state and cloud-init metadata crawler fails and falls back to local DataSource, skipping provisioning of ssh keys etc.

Jun 01 19:45:07 ip-172-31-13-182 ifup[928]: bound to 172.31.13.182 -- renewal in 1373 seconds.
Jun 01 19:45:07 ip-172-31-13-182 ifup[928]: run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1
Jun 01 19:45:07 ip-172-31-13-182 ifup[928]: Failed to bring up ens3.
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: Failed to start Raise network interfaces.
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: Dependency failed for Initial cloud-init job (metadata service crawler).
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: cloud-init.service: Job cloud-init.service/start failed with result 'dependency'.
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: networking.service: Unit entered failed state.
Jun 01 19:45:07 ip-172-31-13-182 systemd[1]: networking.service: Failed with result 'exit-code'.

[... snip ...]

Jun 01 19:45:09 ip-172-31-13-182 cloud-init[1347]: [CLOUDINIT] cc_final_message.py[WARNING]: Used fallback datasource

FWIW, this happened after installing docker.io, which pulls in ubuntu-fan as a dependency.

A manual `/usr/sbin/fanctl net start ens3` exits 1, without any output.

[Mark Shuttleworth (sabdfl)]

Please bump up the importance of this issue. Thanks!

Mark

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-fan - 0.11.0

---------------
ubuntu-fan (0.11.0) yakkety; urgency=medium

  * fanctl: fix net start/stop exit codes. (LP: #1551747)

 -- Andy Whitcroft <email address hidden> Mon, 06 Jun 2016 12:01:45 +0100

[Chris J Arges (arges)]

Hello Zygmunt, or anyone else affected,

Accepted ubuntu-fan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-fan/0.9.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Uli Middelberg (uli-k)]

Version 0.9.1 fixes the bug for armhf and aarch64 in the way that I won't get an error message any more. I don't use a fan configuration so cannot tell anything about possible side effects for (active) fan users.

[Eliezer Croitoru (eliezer)]

A simple docker.io installation can verify if the fix works or not.
Install an ubuntu 16.04 then install docker.io and reboot the system.
In my case it's a 16.04 with docker and kvm on the machine but I will be able to test it only next week.
If until then no one will test I will spin up a vm for the test before applying to production.

[Uli Middelberg (uli-k)]

I've have docker.io installed, but I didn't modify /etc/default/ubuntu-fan nor /etc/network/fan.

[Eliezer Croitoru (eliezer)]

@Uli, It's an automated dependency.

[Uli Middelberg (uli-k)]

> @Uli, It's an automated dependency.
I know.

The question is: Should I modify /etc/network/fan if I'm using private IP addresses outside of 10.254/16, 172.16/12, 192.168/16, e.g. 10/24 ?

[Mark Shuttleworth (sabdfl)]

On 13/07/16 04:32, Uli Middelberg wrote:
>> @Uli, It's an automated dependency.
> I know.
>
> The question is: Should I modify /etc/network/fan if I'm using private
> IP addresses outside of 10.254/16, 172.16/12, 192.168/16, e.g. 10/24 ?

The key thing with the fan is that all the machines participating in a
fan need to have *exactly* the same map.

The map included by default is a recommendation, and we make it so that
most people can "just work" without doing anything else. If the map
doesn't work for you, feel free to modify it, but I would suggest that
you modify it in a way that suits you and copy that map to EVERY machine
that will be participating in your fans.

Mark

[Eliezer Croitoru (eliezer)]

@Mark, @Uli:
Testing the problematic state would be to install docker.io and enable it ie:
apt install docker.io
systemctl enable docker

To test:
reboot
ifdown ens3 && echo "OK"
ifup ens3 && echo "OK"

The test commands will result in two lines with OK at the end if everything is right.
On ubuntu-fan 0.9.0 an interface with dhcp receives an ip but the interface won't show as in up state and the command exits with an exit code higher then 0.
The commands seems to work fine after the update.

[Uli Middelberg (uli-k)]

Version 0.9.1 fixes this bug for armhf and aarch6. I'm using Docker on both platforms and I'm happy to see that the network startup won't get confused any more by ubuntu-fan (like version 0.9.0 did). This is what I can confirm.

What I cannot conform is if 0.9.1 has any impact for people who rely on ubuntu-fan, since I haven't modified /etc/network/fan in a way that it will incorporate with my network settings.

[Andy Whitcroft (apw)]

Confirmed "/usr/sbin/fanctl net start ens3" now exits 0 in the face of an empty configuration.

[Eliezer Croitoru (eliezer)]

@Uli, these users needs to test so when they will have any trouble they would probably bump this or another bug report.
I do not like the concept but this is what we have now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-fan - 0.9.1

---------------
ubuntu-fan (0.9.1) xenial; urgency=medium

  [ Andy Whitcroft ]
  * fanatic: fix legacy command line form syntax error (LP: #1584150)
  * fanctl/fanatic: add help commands/options with initial pointers
    (LP: #1535054)

  [ Jay Vosburgh ]
  * fanatic: fix underlay with calculation (LP: #1584092)

  [ Andy Whitcroft ]
  * fanctl/fanatic: remove invalid web reference from manual pages.
    (LP: #1582956)
  * fanatic: detect user specified underlay address without overlay
    (LP: #1584692)
  * fanatic: switch from lxd-images to using cached lxc images. (LP: #1584775)
  * fanatic: test-host -- use the selected underlay width to calculate the remote addresses
    (LP: #1584878)
  * fanctl: fix net start/stop exit codes. (LP: #1551747)
  * fanatic: install ping and nc when needed (LP: #1586176)
  * fanatic: switch docker testing to lts images (LP: #1586169)

 -- Andy Whitcroft <email address hidden> Mon, 04 Jul 2016 14:35:39 +0100

[Martin Pitt (pitti)]

The verification of the Stable Release Update for ubuntu-fan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[david butler (croepha)]

In Snappy, as a workaround, you can add a /etc/systemd/system/usr-sbin-fanctl.mount
with contents:

[Unit]
Description=suppress fanctl issues
Before=networking.service
After=-.mount

[Mount]
What=/bin/true
Options=bind
Where=/usr/sbin/fanctl

[Install]
RequiredBy=-.mount

[Zygmunt Krynicki (zyga)]

I'm marking this as invalid in snappy as it doesn't seem related to snapd proper.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2623