[Bug 366967] Re: ifupdown-udev integration should be thought-out more thoroghly

[Thomas Hood]

Have you tried upgrading the resolvconf package to the Precise or
Quantal version?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/366967

Title:
  ifupdown-udev integration should be thought-out more thoroghly

Status in “resolvconf” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: ifupdown

  $ lsb_release -rd
  Description:    Ubuntu 9.04
  Release:        9.04

  $ apt-cache policy ifupdown
  ifupdown:
    Installed: 0.6.8ubuntu19
    Candidate: 0.6.8ubuntu19
    Version table:
   *** 0.6.8ubuntu19 0
          500 http://localhost jaunty/main Packages
          100 /var/lib/dpkg/status
       0.6.8ubuntu12 0
          500 http://localhost intrepid/main Packages

  On my system I used Ubuntu 8.10 for some time, as well as earlier Ubuntu versions, starting probably from 7.04.
  On this system I have server+router setup with pretty advanced options in '/etc/network/interfaces' file, including use of 'resolvconf' ('dns-nameservers', also updating 'bind9' and 'squid' configs), as well as submitting 'batch' jobs ('up' commands, to run pptp and pppoe connections soon after corresponding eth iface is brought up, but not before). Of course these actions depend on certain scripts having been run, like, remounting root directory rw, 'resolvconf' initialization, and so on.

  Up to and including Ubuntu 8.10, everything in my setup worked well,
  probably due to the fact that 'ifup' was actually called in
  'rcS.d/S40networking' after all necessary preparations were done. Save
  for the fact that 'at'/'batch' utilities were unable to send a
  notification signal to 'atd' because it was not running then, but that
  was not a big grief as they could submit jobs into the queue directory
  anyway, and 'atd' could see these being started later.

  After upgrade to Ubuntu 9.04, I found that 'ifup' is now called by
  'udevd', very early in the boot process. Before filesystem check.
  Before the root is remounted rw. Before the 'resolvconf' initialized
  and its updates are allowed. So my nice network configuration, that I
  trusted to 'ifupdown' to handle for a long time, breaks. And it breaks
  in the middle of the way. I.e., what does not require storage in the
  filesystem, is still preformed. The iface is up, its
  address/netmask/gateway/routes are configured. But no resolvconf. And
  no at/batch jobs. On the first failed command, 'ifup' stops bringing
  the iface up, does not do any rollback like bringing it down by
  'ifconfig', and on the next run from 'S40networking' it tries to bring
  it up again, stumbling even earlier in the configuration steps.

  Anyway, commenting out the "add" line in "85-ifupdown.rules" have been
  an immensely helpful workaround in my case.

  And even if my iface configs were simple enough, just want you to note another nice possibility of breakage :
  In the same file, '85-ifupdown.rules', there is hardcoded path '/var/run/network', presumably for 'ifupdown' to hold 'ifstate' file in it. Other scripts on the system look to where '/etc/network/run' symlink points. In my setup kept from previous versions of 'ifupdown', it was pointing to '/dev/shm/network'. Okay, thought I at one step of this painful debugging, may be I should switch this symlink to '/var/run/network' as well. And I did so. Now let's look at a scenario. '/var/run' is mounted in 'S02mountkernfs.sh' . 'udev' is started in 'S03udev'. Then who knows what events could be processed by 'udev', may be including some ifups filling the 'ifstate'. Then, in 'S36mountall-bootclean.sh', '/var/run' is dutifully cleaned, removing 'ifstate' in the course. Don't know, may be it is worth to use a directory in '/lib/init/rw', as does 'resolvconf' ?

  So as you see, upgrading from Ubuntu 8.10 to 9.04 happened to be a nice testcase for 'ifupdown'.
  May be my information could be useful to you in further work on the package.
  Lot of pain, yes, but the relief is possible :>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/366967/+subscriptions