Comment 3 for bug 366967

On Wed, 2009-05-06 at 05:48 +0000, Wladimir Mutel wrote:

> Everything I have configured in my /etc/network/interfaces worked for some reason up to and including Ubuntu 8.10.
> I had a look into ifupdown-udev integration in Ubuntu 8.10 and so far did not notice any serious difference with 9.04, but anyway, with 9.04, actions configured in 'interfaces' started to be triggered too early (before the filesystem is remounted rw, before rundirs are cleaned, etc.).
>
This has been the case for a while.

It would help if you could identify what things run from ifup require a
writable filesystem, in general those kinds of things shouldn't.

> Some samples for your consideration :
>
> auto lo eth0
>
> iface lo inet loopback
>
> iface eth0 inet static
> address 192.168.200.240
> netmask 255.255.255.0
> network 192.168.200.0
> broadcast 192.168.200.255
> dns-nameservers 192.168.200.203 192.168.200.202
> dns-search example.dp.ua
> up ip addr add 192.168.201.240/24 dev eth0
> up sysctl -w net.ipv4.conf.eth0.log_martians=0
>
> Worked in 7.*, 8.*. Stopped to work in 9.04.
>
None of this requires a writable filesystem?

> Symptom : resolvconf-related information (dns-* options) is not recorded in resolvconf rundir (/lib/init/rw/resolvconf/interface/), and so resolv.conf is not regenerated with specified options.
> Possible cause : udev is run at S03, and resolvconf rundir is initialized and cleaned only at S07.
> There is an integration between ifupdown and resolvconf, and it is broken by this.
>
This may be a bug in resolvconf in Ubuntu.

> Another symptom : bind9 configuration file in /var/run/bind/named.options is not regenerated, its 'forwarders' list is not updated, left empty.
> Possible cause : clobbered resolvconf rundir at S07, cleaning of /var/run at S36.
> There is an integration between bind9 and resolvconf, and it is broken by this.
>
Likewise sounds like a resolveconf issue.

Note that /var/run is not cleaned in Ubuntu since it's a tmpfs.

> iface lo inet loopback
> up iptables-restore < /home/mwg/its
>
> iface eth0 inet static
> address 172.17.12.15
> netmask 255.255.255.0
> dns-nameservers 172.17.12.1
> up ip rule add from 172.17.12.15 lookup 4
> up ip route add default via 172.17.12.1 table 4
> up ip route add 195.24.128.78 via 172.17.12.1
> up ip route add 195.24.128.75 via 172.17.12.1
> up ip route add 195.24.128.88 via 172.17.12.1
> up echo pon dsl-provider1 | batch
>
> iface eth3 inet static
> address 192.168.1.2
> netmask 255.255.255.0
> up echo pon dsl-provider2 | batch
>
> Symptom : submitting batch job fails, and bringing up the interface fails as a result. At S40, 'ifup -a' is run again, trying to bring up the same interface, and this time failing at 'ip route add' as the route has already been added. IP rule (routing policy) is added twice.
> Possible cause : 'batch' calls 'at -qb' which requires /var/spool/cron/atjobs/ to be accessible r/w. I have my /var in the root filesystem so it becomes remounted r/w only at S10, while udev runs ifup shortly after S03 and probably well before S10.
>
> Workaround : comment out the same line in the same .rules file.
>
That makes sense.

> I don't have an idea why these samples worked for me completely well in 8.10 and before. May be udev has become faster in 9.04, and race conditions started to happen. May be some barrier had been removed which prevented ifup from running too early. Anyway, I hope you will be able to test my samples with 8.10 and 9.04 and reproduce the behaviour I observed.
>
udev is certainly much faster in 9.04, and it's very possible that this
means the race is being lost.

A lot of this integration work dates back to when we still used ifup on
the desktop configuration, and had issues with blocking on DHCP and
suchlike.

Since the desktop now uses Network Manager, a lot of this isn't really
necessary (though we still need to "ifup lo", etc.)

> May be ifup should be taught that complex interface configs are not to
> be processed from under udev and fail immediately in this case. Like,
> if the interface config contains options related to resolvconf,
> wpa-supplicant, or any commands in 'up' options. Or may be, big red
> warning should be included in 'man 5 interfaces' that the user should
> not expect the filesystem to be mounted r/w during interface bring-up,
> which will certainly teach the user about certain limitations of right
> things to do at this moment.
>
I tend to think we should try and fix things to make them right, rather
than tell users what they can't do.

The idea of detecting a complex interface configuration is quite
compelling, deferring the ifup until after the root filesystem is
writable in those cases.

We wouldn't want to do this for the simple cases since you might rely on
the network to be able to bring up the root filesystem (NFS).

Scott
--
Scott James Remnant
<email address hidden>