resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ifupdown (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
resolvconf (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: resolvconf
ifdown -a ; ifup -a fixes the problem after a reboot.
ProblemType: Bug
Architecture: i386
Date: Sat Oct 10 17:55:06 2009
DistroRelease: Ubuntu 9.10
Package: resolvconf 1.44ubuntu1
PackageArchitec
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: resolvconf
Uname: Linux 2.6.31-13-generic i686
PC (pieter-claassen) wrote : | #1 |
- Dependencies.txt Edit (590 bytes, text/plain; charset="utf-8")
- XsessionErrors.txt Edit (969 bytes, text/plain; charset="utf-8")
Anders Kaseorg (andersk) wrote : | #2 |
Changed in resolvconf (Ubuntu): | |
status: | New → Confirmed |
tags: |
added: ubuntu-boot removed: i386 |
summary: |
- On reboot, resolvconf does not pick the dns-nameserver and dns-search - lines up from /etc/network/interfaces. That means you have not DNS + resolvconf starts after ifupdown, does not pick the dns-nameserver and + dns-search lines up from /etc/network/interfaces |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #3 |
Obvious fix is to resolvconf, e.g. by porting to upstart you could "start on starting network-interface"
Changed in ifupdown (Ubuntu): | |
status: | New → Won't Fix |
Wladimir Mutel (mwg) wrote : | #4 |
The crude fix is usual, similar to LP:366967 :
in the file '/etc/init/
comment out the line 'exec ifup --allow auto $INTERFACE'
works for me and my resolvconf, so far.
tags: | added: regression-potential |
tags: |
added: regression-release removed: regression-potential |
Sander van Grieken (sander-vangrieken) wrote : | #5 |
Hi,
I made an upstart script, like Scott suggested, which initialises the resolvconf directory structure. I have it start pre-udev, so it's sure to fire before ifup. It replaces the sysv link in rcS.d, but I also made some changes to resolvconf itself, basically I moved the resolvconf run directory to /lib/init/rw/, to have the earliest available writable filesystem from the start of the boot process.
Anyway, the upstart script is attached, and put the following lines in /sbin/resolvconf
[ -e /etc/default/
RUN_DIR=
(uncomment the old RUN_DIR line of course)
and in /etc/resolvconf
[ -e /etc/default/
DYNAMICRSLVCNFF
(again uncomment the old var)
Sander van Grieken (sander-vangrieken) wrote : | #6 |
oh and symlink your /etc/resolv.conf to /lib/init/
Jürgen Kreileder (jk) wrote : | #7 |
resolvconf actually should already use /lib/init/
Francis Russell (francis-russell) wrote : | #8 |
I'm having difficulty understanding what this script accomplishes. If it it co-exists with the existing init script, then when '/etc/init.
If it's meant to act as a replacement for the start action of the init script, then it at also needs to perform the "update -i" action the original init script does to initialise all the things that listen to resolvconf updates.
I believe Scott was hoping that someone would port the entire resolvconf init script to upstart. In the resolvconf model (I believe) a service restart is considered to merely be a stop followed by a start. The problem with the resolvconf init script is that it makes a distinction between a boot-time start and a restart. Resolvconf will delete the contents of the interface directory on a boot-time start, but not on a restart. I think how to distinguish between the two is a question for the upstart developers as I think it's a requirement that exists outside their current use-cases. Someone please correct me if I'm wrong about this.
Sander van Grieken (sander-vangrieken) wrote : | #9 |
Hmm yeah I wasn't really clear in my prev post.
It definately obsoletes the old sysv init script, which should be removed.
The initialisation part is the most essential and moved to the upstart script. The other actions on the init script are really nothing more than calling (or not) 'update' on resolvconf, but as you can see from /sbin/resolvconf and /etc/init.
But you are right about the 'update -i', that should be added to the upstart script at initialisation.
You are also right about the difference in the old init script about boot-time start and service-restart later. A restart on the old initscript merely calls update. But since I know hardly any upstart specifics I don't know how to define the difference between init() and start() precisely.
The move to /lib/init/rw makes the difference less important though, since /lib/init/rw is clean after each boot, since it's not persistent. When using /etc/resolvconf/run you might encounter leftovers from previous boots, but with /lib/init/rw we could just create the resolvconf structure if it's not there yet, and have subsequent calls to stop/start/restart mimic the old initscript behaviour.
I can make a more complete upstart script if anyone's interested?
Sander van Grieken (sander-vangrieken) wrote : | #10 |
Jürgen, you mean this should be the case in 9.10 or 10.04 ?
dinar qurbanov (qdinar) wrote : | #11 |
hello. firefox and empathy do not work, though ping and host commands work. my internet is set with pppoeconf and is set to connect automatically. currently i fix this with sudo poff dsl-provider and then sudo pon dsl-provider. what is better way?
probably this is because this bug.
dinar qurbanov (qdinar) wrote : | #12 |
by the way i was going to report bug , report bug link in https:/
but fortunately i have seen this bug and this is like what i wanted to report.
Sander van Grieken (sander-vangrieken) wrote : | #13 |
q.dinar, probably not the same bug, since resolving works for you with ping and host
Sander van Grieken (sander-vangrieken) wrote : | #14 |
- resolvconf.conf Edit (383 bytes, text/plain)
Ok I made the upstart script 'restartable', and unified more hardcoded paths into /sbin/resolvconf
- the initialisation of the rundir can now be forced with /sbin/resolvconf -i, and is automatically done by the upstart script when no valid structure is found
- starting and stopping the service now sets the enabled/disabled state via /sbin/resolvconf.
- triggering an update is now only done using /sbin/resolvconf -u
- the rundir can now be queried using /sbin/resolvconf -r
So basically this solves the bug, and also cleans up the scattered resolvconf initialisation
There are probably other scripts in /etc/resolvconf
Sander van Grieken (sander-vangrieken) wrote : | #16 |
dinar qurbanov (qdinar) wrote : | #18 |
i have tried to
"in the file '/etc/init/
comment out the line 'exec ifup --allow auto $INTERFACE' "
but in my case this has not helped.
Sander van Grieken, should i try your files? where is located resolvconf.conf ?
Sander van Grieken (sander-vangrieken) wrote : | #19 |
resolvconf.conf should be saved in /etc/init
Sander van Grieken (sander-vangrieken) wrote : | #20 |
but still, this is probably not the bug you suffer from..
TrReardon (tr-reardon) wrote : Re: [Bug 448095] Re: resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces | #21 |
I've tried your fix Sander and it sort of works. Which is to say that
resolvconf properly runs at boot. HOWEVER, it does not run correctly on
ifdown/ifup:
$ sudo ifdown eth0
[sudo] password for reardon:
resolvconf: Error: /lib/init/
resolvconf: Error: /lib/init/
run-parts: /etc/network/
There is already a pid file /var/run/
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://
Listening on LPF/eth0/
Sending on LPF/eth0/
Sending on Socket/fallback
DHCPRELEASE on eth0 to 192.168.0.1 port 67
resolvconf: Error: /lib/init/
* Reloading /etc/samba/smb.conf smbd only
...done.
$ sudo ifup eth0
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://
Listening on LPF/eth0/
Sending on LPF/eth0/
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.0.198 from 192.168.0.1
DHCPREQUEST of 192.168.0.198 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.0.198 from 192.168.0.1
* Reloading /etc/samba/smb.conf smbd only
...done.
resolvconf: Error: /lib/init/
bound to 192.168.0.198 -- renewal in 2147483648 seconds.
resolvconf: Error: /lib/init/
run-parts: /etc/network/
+Reardon
On Thu, Dec 24, 2009 at 6:47 AM, Sander van Grieken <sander@3v8.net> wrote:
[...]
> but still, this is probably not the bug you suffer from..
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitec
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https:/
>
>
TrReardon (tr-reardon) wrote : | #22 |
I created the directory /lib/init/
idea what should go in here. The whole point of installing resolvconf in
the first place was so that vpn clients would work properly (in my case,
vpnc). But no updates to resolv.conf are made when I connect with vpnc
(this did work with the original script, though the boot case was broken).
+Reardon
On Thu, Dec 24, 2009 at 2:02 PM, TR Reardon <email address hidden>wrote:
> I've tried your fix Sander and it sort of works. Which is to say that
> resolvconf properly runs at boot. HOWEVER, it does not run correctly on
> ifdown/ifup:
>
>
Sander van Grieken (sander-vangrieken) wrote : | #23 |
You should use the /sbin/resolvconf from #17. I made a stupid mistake in the one I posted first.
There's no need to create /lib/init/
dinar qurbanov (qdinar) wrote : | #24 |
in my case also ping ya.ru does not work, but host ya.ru and then ping ip address works.
TrReardon (tr-reardon) wrote : | #25 |
Your solution did not work on reboot. Now when I try ''sudo resolvconf -i'
I get a different error
$ sudo resolvconf -i
mkdir: cannot create directory `': No such file or directory
resolvconf: Error: unable to create
+Reardon
On Fri, Dec 25, 2009 at 11:30 AM, Sander van Grieken <sander@3v8.net> wrote:
[...]
> You should use the /sbin/resolvconf from #17. I made a stupid mistake in
> the one I posted first.
>
> There's no need to create /lib/init/
> should be created at boot, or by calling /sbin/resolvconf -i as root.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitec
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https:/
>
>
Sander van Grieken (sander-vangrieken) wrote : | #26 |
Did you redownload the /sbin/resolvconf replacement? Can you confirm there are no
differences between your copy and the attachment? Because you report the same error the
first /sbin/resolvconf replacement I posted had, and I cannot reproduce your current error
with the current one.
TrReardon (tr-reardon) wrote : | #27 |
My mistake this time. It's working properly now with your updated
/sbin/resolvconf
+Reardon
On Sat, Dec 26, 2009 at 7:16 AM, Sander van Grieken <sander@3v8.net> wrote:
[...]
> Did you redownload the /sbin/resolvconf replacement? Can you confirm there
> are no
> differences between your copy and the attachment? Because you report the
> same error the
> first /sbin/resolvconf replacement I posted had, and I cannot reproduce
> your current error
> with the current one.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitec
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https:/
>
>
Sander van Grieken (sander-vangrieken) wrote : | #28 |
- /sbin/resolvconf Edit (3.6 KiB, text/plain)
Found one more tiny bug. fixed it and replaced /sbin/resolvconf attachment.
TrReardon (tr-reardon) wrote : | #29 |
Ok, I've tried with all your latest, and basically nothing has changed, it's
all still broken. On system boot, resolv.conf remains blank (or rather, it
is created, but with no entries, only the top comment lines).
ifdown/ifup fixes the problem. Same as the Ubuntu release problem.
Have you tried with vpnc or similar tunnel installed?
Does anything from /sbin/resolvconf get logged that I can read or send to
you?
+Reardon
On Sat, Dec 26, 2009 at 7:11 PM, Sander van Grieken <sander@3v8.net> wrote:
[...]
> Found one more tiny bug. fixed it and replaced /sbin/resolvconf
> attachment.
>
>
> ** Attachment added: "/sbin/resolvconf"
> http://
>
> ** Attachment removed: "replacement for /sbin/resolvconf"
> http://
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitec
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https:/
>
>
Sander van Grieken (sander-vangrieken) wrote : | #30 |
ok, time for a full checklist :)
- update /sbin/resolvconf from bug attachment
- update /etc/resolvconf
- install /etc/init/
- remove /etc/rcS.
- make sure /etc/resolv.conf symlinks to /lib/init/
vpn or tunnelling should work as good as before. Nothing has changed for 'late' connections.
debugging is a bit hard, but you can see the non-zero exit code if you boot in rescue mode.
TrReardon (tr-reardon) wrote : | #31 |
I think the problem is that there is a significant post-boot delay before
resolv.conf is updated. It took ~ 90sec (after gdm start) on last boot.
But at least it's working
+Reardon
On Mon, Dec 28, 2009 at 5:11 AM, Sander van Grieken <sander@3v8.net> wrote:
[...]
> ok, time for a full checklist :)
>
> - update /sbin/resolvconf from bug attachment
> - update /etc/resolvconf
> - install /etc/init/
> - remove /etc/rcS.
> - make sure /etc/resolv.conf symlinks to
> /lib/init/
>
> vpn or tunnelling should work as good as before. Nothing has changed for
> 'late' connections.
>
> debugging is a bit hard, but you can see the non-zero exit code if you
> boot in rescue mode.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and
> dns-search lines up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “ifupdown” package in Ubuntu: Won't Fix
> Status in “resolvconf” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: resolvconf
>
> ifdown -a ; ifup -a fixes the problem after a reboot.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Oct 10 17:55:06 2009
> DistroRelease: Ubuntu 9.10
> Package: resolvconf 1.44ubuntu1
> PackageArchitec
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> SourcePackage: resolvconf
> Uname: Linux 2.6.31-13-generic i686
>
> To unsubscribe from this bug, go to:
> https:/
>
>
Changed in resolvconf (Ubuntu): | |
assignee: | nobody → MOTU (motu) |
Wladimir Mutel (mwg) wrote : | #32 |
It feels somewhat strange that resolvconf is relegated to 'universe' in Ubuntu.
In Debian, its role is pretty infrastructural. And it is quite closely related with ifupdown.
Sander van Grieken (sander-vangrieken) wrote : | #33 |
Yes I thought that too, Universe is not the place for resolvconf.
But anyway, it seems no one from Ubuntu is interested in this bug?
dinar qurbanov (qdinar) wrote : | #34 |
bug report about my case: https:/
pppoeconf autoconnect does not work fully in ubuntu 9.10".
Will (will-berriss) wrote : | #35 |
Just to say I have this bug too. :(
Symptom:
After a reboot, /etc/resolv.conf contains only this:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 10.18.4.3
nameserver 10.18.4.1
There is no search domain, yet I specified it in /etc/network/
dns-nameservers 10.18.4.3 10.18.4.1
dns-search blah.co.uk fudd.co.uk
However, if I now issue the following command :
$ sudo /etc/init.
It fixes /etc/resolv.conf, as per this:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search blah.co.uk fudd.co.uk
nameserver 10.18.4.3
nameserver 10.18.4.1
Can't wait till this is fixed.
Sander van Grieken (sander-vangrieken) wrote : Re: [Bug 448095] Re: resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces | #36 |
Yeah I'm actually stunned that such a design failure is not acted upon by Ubuntu. Guess
they just capitalize on the work done by Debian, without having to do the hard work of
actually maintaining a distribution.
However this bug MUST sting on servers and 'old-school' people that use
/etc/network/
net that suggest solutions involving /etc/network/
Just apply the new versions of resolvconf files attached to the bug and your problems will
be gone, at least until the upgrade to 10.04 :-/
I myself am moving to Debian ASAP
grtz,
Sander
On Sunday 07 February 2010 10:25:55 you wrote:
[...]
> Just to say I have this bug too. :(
>
> Symptom:
>
> After a reboot, /etc/resolv.conf contains only this:
>
> $ cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
> OVERWRITTEN nameserver 127.0.0.1
> nameserver 10.18.4.3
> nameserver 10.18.4.1
>
> There is no search domain, yet I specified it in /etc/network/
> as follows:
>
> dns-nameservers 10.18.4.3 10.18.4.1
> dns-search blah.co.uk fudd.co.uk
>
>
> However, if I now issue the following command :
>
> $ sudo /etc/init.
>
> It fixes /etc/resolv.conf, as per this:
>
> $ cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
> OVERWRITTEN nameserver 127.0.0.1
> search blah.co.uk fudd.co.uk
> nameserver 10.18.4.3
> nameserver 10.18.4.1
>
> Can't wait till this is fixed.
Bruce Miller (brm0423) wrote : | #37 |
Duplicate Bug #548576 reports this same problem in Kubuntu Lucid Lynx Beta 1 amd64 daily disks of 2010-03-25 and 2010-03-27.
On this network, individual hosts are set up to use DHCP and individual nameservers are not listed in /etc/network/
Circumstances leading to triggering this bug were unusual:
The "install software" step of the installation process failed. (See Bug #548572; probable cause: failure of command: apt-cdrom add )
At the reboot after install, very little software was installed. Although I am not an IT professional and thus inexpert in these matters, I suspect that dhclient read the nameserver data from the router and used it to populate /etc/resolv.conf
I then installed the entire set of packages from a list which I keep routinely updated (using dpkg --set-selections < <listname>. I suspect that that process installed NetworkManager. During the same session, I also installed the proprietary video driver.
The video driver necessitated a further reboot. At this point, /etc/resolv.conf was empty. I had only local network connectivity. None to the internet.
I have worked around the problem by saving the original resolv.conf to a separate file, and running a three-line script to copy it back, and restart networking. I count this as hands-down my ugliest kludge in 28 years of breaking development software.
Mathieu Marquer (slasher-fun) wrote : | #38 |
Also affects me on a machine installed with Ubuntu Lucid Alternate AMD64 beta 1. On each start, the file /etc/resolv.conf is empty although dns-servers are correctly specified in /etc/network/
Simon Huerlimann (huerlisi) wrote : | #39 |
I've created a resolvconf package incorporating the fixes to port resolvconf to upstart from Sander van Grieken. It's available from my PPA at https:/
Please test if it works as expected and give feedback if not.
@Ubuntu guys: tell me what to do to enhance the changes of this (or another) fix being added to Lucid.
Anders Kaseorg (andersk) wrote : | #40 |
Simon: Your resolvconf “1.45ubuntu1ppa1” is actually version 1.44, which seems … really odd. A patch that reverts all the changes between 1.44 and 1.45 as a side effect is certainly not going to make it into Lucid. You’ll need to post a clean debdiff against the current Lucid package with no extraneous changes before it can be considered.
Simon Huerlimann (huerlisi) wrote : | #41 |
Andres: You're absolutely right. I've just created a "correct" karmic package, but was in need for a fixed package for lucid an hour ago. My "fix" was to just bump the package version to get it built on lucid.
Will work on an updated lucid package and repost. The karmic package should be okay to test, though.
Anders Kaseorg (andersk) wrote : | #42 |
FYI, you can install a particular version of a package (even if it is a downgrade) by running
sudo aptitude install resolvconf=
There is no need to artificially inflate the package’s version number.
Simon Huerlimann (huerlisi) wrote : | #43 |
Anders: Thank you for the tip! A "rebased" version is currently building/publishing in my PPA. Should soon be available.
Changes to 1.44ubuntu1ppa2:
* using 1.45ubuntu1 as base
* cleaning up debian/changelog to only have one new version
* using LP: instead of Closes: to close Launchpad bug, not Debian bug ;-)
Will attach debdiff.
Simon Huerlimann (huerlisi) wrote : | #44 |
Mmh, just found a bug, please wait for ...ppa3 before testing. Sorry
Simon Huerlimann (huerlisi) wrote : | #45 |
Okay, uploaded resolvconf-
Changes to resolvconf-
* added /sbin/resolvconf version by Sander van Grieken (which was forgotten in last upload)
* updated postinst and prerm to directly use resolvonf to enable/disable updates instead of init.d/resolvconf
I did have a look at the changes Sander did to /sbin/resolvconf. They seem sensible as they mostly move enable/disable functionality from the now "absent" init.d script to resolvconf.
Simon Huerlimann (huerlisi) wrote : | #46 |
- Debdiff resolvconf-1.45ubuntu1 (lucid) => resolvconf-1.45ubuntu1ppa4 (hPPA) Edit (10.3 KiB, text/plain)
Simon Huerlimann (huerlisi) wrote : | #47 |
@Ubunteros: can I do anything to get this in for Lucid? Look out for a sponsor, do some bikesheding on the package, anything?
Lucid is a LTS release and expected to be more stable than other releases. And this is a genuine regression compared to the last LTS. I understand that resolvconf is in universe and not part of the supported core, and that's the reason why I try to help out.
So I repeat my request: Please give me any hints on how to enhance the chances of this (or another) fix be included in Lucid.
Thanx for this great distribution, anyway;-)
Simon Huerlimann (huerlisi) wrote : | #48 |
Maybe someone with the necessary right could raise the importance of this bug. I mean, this bug makes resolvconf doing DOS on LTS upgrades from hardy, but even bug #60518 did get 'medium'.
I also did some bug triaging to make this one stand out more;-)
Sander van Grieken (sander-vangrieken) wrote : | #49 |
Thanks Simon for packaging this for Lucid, much appreciated.
My currently installed resolvconf package notes the following contacts as maintainers:
Maintainer: Ubuntu MOTU Developers <email address hidden>
Original-
So... you could try sending a notification to the MOTU devs, but they should have been made aware through this launchpad system already. The whole MOTU thing looks like a catchall anyway, so I think resolvconf in Ubuntu is just a Debian copypaste job. They should rename to COTU (Copy Of The Upstream). I think you'll have more luck contacting the debian maintainer...
Sander van Grieken (sander-vangrieken) wrote : | #50 |
I just upgraded to lucid and installed your PPA package.
Of course I forgot to check the situation before installing your PPA package, but anyway, I ended up with a different /etc/resolv.conf link. A quick check reveals that the postinst script in the deb is (re)creating the link to /etc/resolvconf
Also in postinst is some initialization of the resolvconf directories that should now be done by /sbin/resolvconf.
Anyway, I restored the link and everything works as it should, thanks!
Simon Huerlimann (huerlisi) wrote : | #51 |
Hi Sander
Thanks for the report. Will check, fix, release. (Hopefully... ;-)
Wladimir Mutel (mwg) wrote : | #52 |
Ubuntu 10.04 : misbehaviour is still present. Hope to see resolvconf better integrated with ifupdown&upstart in the near future .
Simon Huerlimann (huerlisi) wrote : | #53 |
@Sander: took much longer to find some time to fix the /lib/init/rw vs. /var/lib bug. The postinst script is full of checks to handle all kinds of setups. Not sure how much of that is really needed. But as I don't get the idea of all of it, I just leave it. Regarding the comment in the beginning about /lib/init/rw: a few lines below, there is a copy of the same comment with another comment saying it is not valid for ubuntu, as ubuntu provides an early tmpfs... Well, I guess it wouldn't hurt to stay closer to Debian and use /lib/init/rw anyway. I haven't found time to check the initialization part you mentioned...
@Wladimir Mutel: Yes, the resolvconf package in Lucid still has this nasty bug. But Sander van Grieken did code up an upstart based version of it, and I did some packaging.
You may try my package from my PPA at https:/
Will try to mail the last maintainer of resolvconf about this and ask him to either release a fixed version or sponsor an upload of my package...
Sander van Grieken (sander-vangrieken) wrote : | #54 |
Since I haven't been looking at this bug for a while, I'll just dump my ideas of what IMO should be done in the postinst (and maybe other) package scripts, before I forget them.
There's a couple of situations that should be handled:
a) installing resolvconf while being in a non-resolvconf state
b) upgrading resolvconf that has it's data in another place than the new resolvconf expects it to be (NOTE: which isn't necessarily /lib/init/rw! It's actual location is defined in /etc/default/
In situation A, the problem is that resolvconf doesn't have the information yet to populate resolv.conf, so it should not be activated until reboot, or at least until networking is restarted. It's of course possible to already set up the right /etc/resolv.conf symlink, but the active /etc/resolv.conf should be copied into resolvconf's symlink target file verbatim, and should not be re-generated by resolvconf (possibly by implicitly disabling updates). This is a problem that already exists with the 'official' resolvconf, so it's not a new problem.
In situation B I think we should copy the 'interfaces' folder from the old location over to the new location, maybe in combination with some validity checks to see if the information there matches the active network interfaces. The place of the old location might be deduced from the /etc/resolv.conf symlink, and/or from the old default location under /var. Also maybe cleanup the files at the old location.
If I missed any other situations that might give rise to problems, please add them to this bugreport!
Jürgen Kreileder (jk) wrote : | #55 |
resolvconf (1.45ubuntu1ppa5) karmic; urgency=low
* Use /var/run in resolvonf binary.
-- Simon Huerlimann (CyT) <email address hidden> Mon, 03 May 2010 00:27:16 +0200
Why RUN_DIR=
That's what your postinst and apparmor use.
Simon Huerlimann (huerlisi) wrote : | #56 |
@Jürgen: Oops, my bad. Thank you! Fixed PPA upload is on the way...
@Sander: Sounds very reasonable. I have a hard time really understanding all the tests and checks the original postinst does:-( What you propose sounds like a straight and clean solution. I'll probably won't find the time to implement, though... It probably makes sense to forward your thoughts to the Debian BTS, as you said some time ago: Ubuntu doesn't seem to really care about this package...
Gabriel de Perthuis (g2p) wrote : | #57 |
Here is my quick fix, it just moves resolvconf directory creation earlier and disables invocation from rcS.d since the init.d script doesn't support running twice:
sudo update-rc.d resolvconf disable
sudo tee /etc/init/
description "Prepare resolvconf directory"
start on (starting network-interface
or starting network-manager
or starting networking)
pre-start script
invoke-rc.d resolvconf start
end script
EOF
Kevin Hamer (khamer) wrote : | #58 |
Gabriel's quick fix (#57) didn't work for me. Bug #550962 (marked as a duplicate of this bug) mentions adding
invoke-rc.d networking restart
to rc.local, so I'm going to try that. Rather frustrating, as this is even more problematic in ubuntu server, where NetworkManager isn't even an option.
Sander van Grieken (sander-vangrieken) wrote : | #59 |
Why not just install Simon's package?
Sander van Grieken (sander-vangrieken) wrote : | #60 |
@Simon: Hopefully Debian will pickup the changes that cleanup the hardcoded paths, but as I found out they don't use upstart, so those parts will be useless to them. So we're stuck with MOTU :)
If I find the time I'll take another look at the packaging scripts, so at least the symlink setup works more reliably..
Kevin Hamer (khamer) wrote : | #61 |
I'll try out and update how Simon's package does with ubuntu server 10.04 tomorrow.
Changed in resolvconf (Ubuntu): | |
assignee: | MOTU (motu) → nobody |
Sander van Grieken (sander-vangrieken) wrote : | #62 |
Fabrice, can you at least add an explanation why you unassigned MOTU?
Do you mean this bug will be a WONTFIX?
Anders Kaseorg (andersk) wrote : | #63 |
No, just that bugs should not in general be assigned to MOTU. They should be assigned to a specific person who is actively working on the bug (if any). As you can see, the bug is still Confirmed.
The next thing that needs to happen is that someone needs to propose a debdiff for sponsorship: a clean diff with no extraneous changes, and a single changelog block with an Ubuntu version number (not the version number that gets uploaded to a PPA), based on the current version in maverick.
Stefano Rivera (stefanor) wrote : | #64 |
> The next thing that needs to happen is that someone needs to propose a debdiff for sponsorship
In that case, unsubscribing ubuntu-sponsors
tags: | added: patch |
Liraz (liraz-siri) wrote : | #65 |
Many thanks to everyone who helped track down this regression, which effected TurnKey Linux users of the new TurnKey Core Lucid-based beta as well:
https:/
IMHO, for desktop usage upstart has great potential. But for servers it's a net loss. Booting a few seconds faster doesn't matter as much as stability and simplicity. I just wish there was some way to save all of this asynchronous cleverness for the desktop. In a few years once Ubuntu and Debian transition fully to upstart we should be OK, but now it's ugly out there.
Sander van Grieken (sander-vangrieken) wrote : | #66 |
On Wednesday 15 September 2010 19:27:47 Liraz wrote:
> Many thanks to everyone who helped track down this regression, which
> effected TurnKey Linux users of the new TurnKey Core Lucid-based beta as
> well:
>
> https:/
>
> IMHO, for desktop usage upstart has great potential. But for servers
> it's a net loss. Booting a few seconds faster doesn't matter as much as
> stability and simplicity. I just wish there was some way to save all of
> this asynchronous cleverness for the desktop. In a few years once Ubuntu
> and Debian transition fully to upstart we should be OK, but now it's
> ugly out there.
Hmm I'm starting to doubt that, since many distributions are moving to systemd, and none
except Ubuntu (and derivatives) to upstart. This will likely mean that most upstream
projects will not take upstart into consideration, so Ubuntu alone will have to maintain
it. If this bug is any indication......
Liraz (liraz-siri) wrote : | #67 |
Isn't Debian still planning on moving to upstart? If so that would be a major vote of confidence and would guarantee upstart sticks around for a while longer.
systemd looks very neat. That both RedHat and OpenSUSE are moving to adopt it is telling but I don't think it's very likely Ubuntu will give up upstart any time soon. More likely we'll see some borrowing of code and ideas. FWIW, SysVinit compatibility is the highest on my wishlist.
OTOH, if Debian decide to move to systemd all bets are off. In that case I hope Ubuntu does the right thing and chucks upstart out rather than increase Ubuntu's divergence from the rest of the Linux world.
Sander van Grieken (sander-vangrieken) wrote : | #68 |
My apologies, I have to backtrack on my prev statement. I thought to have read that on LWN
some time in the past, but I cannot find such statement anymore through google.
Fact is, that Debian hasn't moved to upstart OR systemd (or initng for that matter) yet,
even in unstable, and is using insserv (optional) to parallelize the boot sequence. They
are still contemplating which direction to take.
see
http://
http://
and the most recent announcement
http://
.. where upstart is described as 'the most promising candidate'.
Again, sorry for the confusion :)
On Monday 27 September 2010 11:52:48 you wrote:
[...]
> Isn't Debian still planning on moving to upstart? If so that would be a
> major vote of confidence and would guarantee upstart sticks around for a
> while longer.
>
> systemd looks very neat. That both RedHat and OpenSUSE are moving to
> adopt it is telling but I don't think it's very likely Ubuntu will give
> up upstart any time soon. More likely we'll see some borrowing of code
> and ideas. FWIW, SysVinit compatibility is the highest on my wishlist.
>
> OTOH, if Debian decide to move to systemd all bets are off. In that case
> I hope Ubuntu does the right thing and chucks upstart out rather than
> increase Ubuntu's divergence from the rest of the Linux world.
>
> --
> resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines
up from /etc/network/
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Sander van Grieken (sander-vangrieken) wrote : | #69 |
I just upgraded one of my systems to Maverick, and the bug seems to be solved out-of-the-box there.
However, it seems that they just dropped in the upstart script from this bug without much thinking, resulting in somewhat of a mutant resolvconf, because
a) the upstart script assumes the modified /sbin/resolvconf from this bug, i.e. it gets called with -r -i --enable-updates --dsiable-updates options, but the provided /sbin/resolvconf is not aware of these options.
b) there's a link to start resolvconf from /etc/rcS.d, while there's also an upstart script (?!). The fact that /etc/init.
Third, resolvconf's data has been moved again back to /etc/resolvconf
So, it works at boot, but there's no enabling/disabling updates (start/stop resolvconf service) and no initialisation of the volatile directory structure by /sbin/resolvconf itself. This directory structure is probably instead prepared during install by the packaging scripts.
Sander van Grieken (sander-vangrieken) wrote : | #70 |
Ehh? Changelog of resolvconf doesn't match reality?
Or am I looking in the wrong spot?
https:/
* Merge from debian unstable (LP: #605116), remaining changes:
- bin/resolvconf:
+ fail with non-zero exit code when /etc/resolv.conf is not a symlink.
- debian/postinst:
+ use default /var/run.
+ make sure all run files are sent to /var/run, not /lib/init/rw
+ update regex to check that /var/run is a tmpfs (LP: #386822)
+ fix typo in comments
- debian/rules:
+ don't install the init script in runlevels 0 and 6.
- debian/postrm:
+ remove /var/run/
+ also purge /var/run/
Anders Kaseorg (andersk) wrote : | #71 |
Sander van Grieken: I’m not sure what you’re talking about, there’s no Upstart script in the Ubuntu resolvconf package [1]. Perhaps you previously had the PPA package installed and it’s left over from that (note that dpkg will not delete conffiles by default [2])?
[1] http://
[2] http://
Sander van Grieken (sander-vangrieken) wrote : | #72 |
I'm talking about the actual package Anders. Apparently the package contents are incorrect at your [1] link.
$ dpkg -l | grep resolvconf
ii resolvconf 1.46ubuntu1 name server information handler
$ apt-cache showpkg resolvconf
Package: resolvconf
Versions:
1.46ubuntu1 (/var/lib/
$ dpkg -L resolvconf | grep /etc/init/
/etc/init/
Jürgen Kreileder (jk) wrote : | #74 |
As Anders said, conffiles don't get deleted by default.
Do 'dpkg -s resolvconf | grep /etc/init/', you should see that /etc/init/
Sander van Grieken (sander-vangrieken) wrote : | #75 |
Ok my bad :)
I never thought of the /etc/init.d initscripts as 'config' files (and I guess no package marks them as such) so I extended this assumption to the upstart scripts too..
Never really used the '-s' option, thanks for the tip.
Anders Kaseorg (andersk) wrote : | #76 |
/etc/init.d scripts are treated as configuration files too, as specifically mandated by Debian Policy [1]. By default, all files in /etc are marked as conffiles by Debhelper [2]. This is important for whoever’s working on this bug, because you will need to write code to specifically clean up the old-style init script; the necessary code is given on the Debian Wiki page I linked to earlier [3].
[1] http://
[2] http://
[3] http://
Jürgen Kreileder (jk) wrote : | #77 |
I've put a fixed build of resolvconf for maverick on https:/
The package contains the changes made by Simon Huerlimann and Sander van Grieken.
Source code is available via above PPA and https:/
Sander van Grieken (sander-vangrieken) wrote : | #78 |
Jürgen, I installed your deb, but it fails to create the /var/run/resolvconf directory. Also the /etc/resolv.conf symlink still points to /etc/resolvconf
output of dpkg -i :
Preparing to replace resolvconf 1.46ubuntu1 (using resolvconf_
Unpacking replacement resolvconf ...
Setting up resolvconf (1.46ubuntu1ppa1) ...
Installing new version of config file /etc/resolvconf
touch: cannot touch `/var/run/
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Jürgen Kreileder (jk) wrote : | #79 |
Sander, looks like a bug inherited from the lucid package. The postinst script must run "resolvconf -i" instead of "resolvconf --enable-updates". I'll upload a fixed package in a few minutes. (The current package should work after "start resolvconf", though).
Jürgen Kreileder (jk) wrote : | #80 |
The new package is in ppa:jk/ubuntu-fixes now. postinst now runs "resolvconf -i" if the run dir doesn't exist yet.
dm (jan-rauberg) wrote : | #81 |
The new package ppa2 does not work as expected in Maverick. After every start I have to do a dpkg-reconfigure resolvconf. Otherwise /etc/resolv.conf is a dead link. Then I have to restart networking an NIS. This is very annoying. I thing the ppa1 was good.
Jürgen Kreileder (jk) wrote : | #82 |
ppa2 only changed the postinst script, so the error should have been in ppa1 too.
To what does /etc/resolv.conf point and does /var/run/resolvconf exist after booting?
Juri Haberland (haberland) wrote : | #83 |
Sander et al.,
I found a problem in the upstart config file from your resolvconf patch:
> start on ( virtual-filesystems and starting udev )
This makes a "restart udev" hang, because upstart waits for resolvconf to finish, which will never happen, as it waits for the signal "virtual-
Changing the 'start on' line to:
> start on starting udev
fixes this problem.
dyna (ubuntu-dyna) wrote : | #84 |
Bug present in 11.04 natty aswell.
Most of the times resolv.conf is empty expect for 2 remarked generated-
Only about 1 of 10 reboots resolv.conf will get filled correctly with dns-* data from the interfaces file.
Please fix this, correct dns info is pretty important for servers which do not use dhcp-client.
Craig Constantine (craig-constantine) wrote : | #85 |
...just removing ("apt-get purge resolvconf") the package fixes the problem for me.
I don't need the /etc/resolv.conf file being dynamically modified. Simply purge the package, remove the "# this file is auto generated..." comment in /etc/resolv.conf and my problem is solved.
Miguel Branco (mpbbranco) wrote : | #86 |
I'm reluctant to apply the PPA because I fear that if it breaks I will not be able to recover. Could someone summarize/update the cli steps as done by SvG in the past for 11.10 ? I've tried these manual steps but it broke my networking startup (i.e., updated resolvconf, libc, init/resolv.conf, removed rcS.d/S07, updated symlink). I could recover by backing up the original files. My S07 script is activated at startup so should I disable it with update-rc and exactly how ?
Miguel Branco (mpbbranco) wrote : | #87 |
Nevermind, the quickfix from GdP seems to have worked as is.
Thomas Hood (jdthood) wrote : | #88 |
Hi Miguel.
I would very much appreciate it if you and other contributors to this bug thread would test the latest resolvconf package at https:/
--
Thomas Hood
Daniel Stensnes (dstensnes) wrote : | #89 |
Good lord. Will someone please assign this stuff to someone? I need this for openvpn to my work place. It has been open for several years already....
Thomas Hood (jdthood) wrote : | #90 |
This should be fixed already in 1.63ubuntu8, available in the Precise repo.
Sven Kieske (s-kieske) wrote : | #91 |
Thomas Hood:
I must decline that this is fixed.
How my system is setup:
Ubuntu 12.04.3 LTS Server minimal installed.
I have booted a system without /etc/network/
I created /etc/network/
to check for new entries to add to resolv.conf.
ifup works, the ip-address and routes get assigned, however the dns-nameservers do not get assigned.
apt-cache showpkg resolvconf shows me the version: 1.63ubuntu16
Thomas Hood (jdthood) wrote : | #92 |
Please post your /etc/network/
Yeah, apparently ifupdown starts before resolvconf now.