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

[Steve Langasek]

On Tue, Feb 21, 2012 at 09:26:17PM -0000, Steffen H. wrote:
> I had an up-to-date Ubuntu 11.10 workstation.

> I recently received an update that required a 'restart' (aka reboot - new
> kernel).  I put off the reboot while working away - for a week or so.  So,
> as has happened each time I've had to 'restart' (aka reboot for a new
> kernel), I once again watched in disgust as my /etc/resolv.conf file got
> blown away.

The Ubuntu bug tracker is a place for users to report bugs and work with
developers to resolve them.  You have followed up to an existing bug report
without subscribing to it, providing only a vague description of the problem
("something" overwrote /etc/resolv.conf) and giving no reason to think your
message is related to this closed bug report.

You should not expect the Ubuntu developers to take any action in response
to such a message.

> Is anyone EVER going to allow an Ubuntu system administrator to
> configure their networking set up via some /etc file contents.  Is some
> GUI now mandatory?

This has worked flawlessly for the vast majority of Ubuntu users since
Ubuntu's inception.

> As others have noted, I now find that ifdown/ifup works - albeit only
> once I conform to the Ubuntu way and put a dns-nameservers directive
> into the eth0 stanza in /etc/network/interfaces.

This sounds like you did have resolvconf installed.  Resolvconf has never
been part of a standard Ubuntu install prior to 12.04, was unmaintained in
the Ubuntu archive and was in a known-broken state (as this and other bug
reports attest).  The obvious solution if you aren't happy with the output
of resolvconf, a package which exists for the *sole purpose* of updating
/etc/resolv.conf, is to uninstall the package.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org

-- 
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