/etc/rcS.d/S07resolvconf is too early

[Brian J. Murrell]

Binary package hint: resolvconf

In current jaunty, resolvconf is started in /etc/rcS.d/S07resolvconf.

This is before local filesystems are mounted however. The result is that if /var/ is on it's own filesystem, $RUN_DIR(=/etc/resolvconf/run) is pointing to a directory that is not yet mounted: /etc/resolvconf/run -> /var/run/resolvconf.

This of course causes resolvconf problems when /var is mounted on top of all of the work that /etc/rcS.d/S07resolvconf has done.

[Brian J. Murrell (brian-interlinx)]

And of course, that /var/run is a tmpfs makes this problem all the more interesting. I'm not really sure where the popcorn trail on that leads.

[Wladimir Mutel (mwg)]

Probably that's why it is strongly recommended to point your /etc/resolvconf/run to /lib/init/rw/resolvconf
/lib/init/rw is very similar to /var/run , but it is available even earlier in the boot process, specially for these purposes.
Just look into resolvconf postinstallation script and find this out for your self.
Probably your symlink was left from a previous configuration.

And may be resolvconf postinst script should be more insistent about checking where this symlink points and switching it to /lib/init/rw/ in case of any violations.

[Brian J. Murrell (brian-interlinx)]

On Fri, 2009-05-08 at 05:51 +0000, Wladimir Mutel wrote:
> Probably that's why it is strongly recommended to point your /etc/resolvconf/run to /lib/init/rw/resolvconf

*I* should do that? I've never pointed it anywhere. The package has
decided where it should be and put it there.

> /lib/init/rw is very similar to /var/run , but it is available even earlier in the boot process, specially for these purposes.

OK. So why is it not being used, and/or previous installations being
converted to use it?

> Just look into resolvconf postinstallation script and find this out for your self.

Hrm. I don't see that. If everything falls through to the "it's not
there (yet)" case:

  # It's a nonexistent
  # Use /var/run.
  if \
   [ -d /var/run ] \
   && [ -w /var/run ] \
   && grep -qs "^tmpfs[[:space:]]\+/var/run[[:space:]]\+tmpfs[[:space:]]\+\([^[:space:]]\+,\)\?rw" /proc/mounts \
   && { [ -d /var/run/resolvconf ] || mkdir -v /var/run/resolvconf ; } \
   && { [ -d /var/run/resolvconf/interface ] || mkdir -v /var/run/resolvconf/interface ; }
  then
   ln -s /var/run/resolvconf /etc/resolvconf/run
  else
   mkdir -v /etc/resolvconf/run /etc/resolvconf/run/interface
  fi

So that looks to me like it's using /var/run if nothing else.

The only time it appears to use /lib/init/rw/ is if /dev/shm/resolvconf
was being used previously.

> And may be resolvconf postinst script should be more insistent about
> checking where this symlink points and switching it to /lib/init/rw/ in
> case of any violations.

Yes. If all installations are supposed to use /lib/init/rw then IMHO,
the postinst should be moving existing installations there.

[Grant Bowman (grantbow)]

Maybe I missed it, but I didn't see any kind of "strong recommendation" in the documentation. Who recommends this and where? Won't there also need to be changes within the package as well as the post-install script to use the new location? Wladimir Mutel, if you know how the package should work, can you provide some patches to begin fixing this so everyone can benefit?

With Comcast's messing around with DNS servers this package seems to be a great solution to my new system needs.

[Wladimir Mutel (mwg)]

Sorry for misinforming you all. My fault.
Now the problem seems to be fixed in Ubuntu package management scripts. The directory location is checked and fixed when needed.
Earlier, there were some mess with resolvconf keeping its mutable state in /etc and requiring /etc (/) to be mounted rw too early in the boot process. Or may be this was just a legacy from my Debian unstable which I updated to Ubuntu 7.10 (or 8.04?) at some point.

[Sander van Grieken (sander-vangrieken)]

see also #448095

[Grant Bowman (grantbow)]

This bug is for Jaunty 9.04. I don't know it's current status.

LP:448095 is for Karmic 9.10, which is very different. Karmic uses Upstart instead of the older init scripts.