18

After editing dns-nameservers in /etc/network/interfaces, how do I tell resolvconf(8) to read the new value without restarting networking? (causing a service interruption)

The -u option doesn't seem to work, it just updates back to the same values.

1
  • 1
    not sure this is possible. restarting network only takes 3 seconds anyway. Oct 19, 2012 at 23:07

3 Answers 3

27

You are right, "resolvconf -u" does not suffice to activate the change you made. That command only updates resolv.conf from resolvconf's database whereas you need to update the database.

Assume the interface in question is eth0. Assume that in /etc/network/interfaces you have a stanza that looks like this.

iface eth0 inet static
    [...]
    dns-nameservers 1.1.1.1 2.2.2.2

Now you change the "dns-nameservers" line. To activate this change do (note the && avoid breaking a potentially open ssh connection)

ifdown eth0 && ifup eth0

or reboot.

5
  • 6
    As the OP says, this will cause a service interruption. What's more, issuing ifdown eth0 will probably kill your ssh connection, so the ifup will never get the chance to run, cutting you off from your server and preventing you getting back in!
    – Synchro
    Nov 14, 2012 at 8:44
  • 1
    You are right, although the OP didn't say that he was logged in via ssh and only asked how to avoid restarting networking. I will shortly provide another answer which addresses the case you describe.
    – jdthood
    Nov 14, 2012 at 19:47
  • I posted the answer here: askubuntu.com/questions/224966/…
    – jdthood
    Dec 13, 2012 at 9:43
  • 2
    I know this is a late answer, but you can do ifdown eth0 && ifup eth0, it doesn't interrupt SSH (tested).
    – Fusseldieb
    Nov 11, 2016 at 21:35
  • sudo service networking reload should be sufficient. No interruption to ssh connection
    – ttimasdf
    May 17, 2019 at 7:45
13

I bumped into this twice recently.

The first time, I did sudo ifdown eth0 which of course killed my ssh connection and left the machine ignoring its NIC. Ouch. I had to go in through the IPMI interface on the server to get control again.

The second time, I learned from my earlier mistakes and did sudo ifdown eth0 ; sudo ifup eth0. The ssh window died, of course, but the machine quickly responded to a new ssh connection and my DNS modifications were in effect. I did the same thing on a second server but this time I waited before typing anything into the ssh window. The window stayed up and the DNS changes had been applied. Awesome.

The critical thing was to use the shell's semicolon operator so that both commands would be on one line. This way, the command to restore the interface has already been entered by the time the interface goes down. I suppose I could have written a script and executed that, but this seemed easier.

UPDATE: There is another way to do this. You can also restart the Ubuntu networking service in one step: sudo /etc/init.d/networking restart or sudo service network-interface restart INTERFACE=eth0. Thanks JFA for the inspiration.

7
  • Why wouldn't you want to restart the connection though?
    – jfa
    Jun 6, 2014 at 1:47
  • 1
    There was nothing wrong with the SSH connection to the server in question. That server just needed its DNS settings adjusted. Jun 6, 2014 at 3:41
  • 1
    @RandalCook I mean why is shutting down and bringing eth0 back up better than restarting the service? They both terminate the connection anyway.
    – jfa
    Jun 6, 2014 at 14:54
  • 1
    Networking is so fundamental I didn't know there was a service to restart. It seems like a good alternative. Thanks for cluing me into that approach, @JFA. I added it to my answer. Jun 6, 2014 at 17:42
  • 1
    +1 for sudo ifdown etho ; sudo ifup eth0 Jul 12, 2015 at 14:25
2

Just went through this same issue; even a reboot would be lose the change on manually invoking the libc hook.

So the most stable way I've found is, after putting the desired content into /etc/network/interfaces, to edit /etc/resolvconf/resolv.conf.d/original to include the lines wanted, make sure tail (in that directory) is not present, cd /etc/resolvconf/resolv.conf.d and then invoke /etc/resolvconf/update.d/libc.

Note that if tail is present (by default, pointed to original then the contents derived from /etc/network/interfaces will be followed by the original setup too.

That these changes can most safely be applied by a reboot is, frankly, insane. The current system takes what used to be "edit this file, perhaps deploying from a configuration management system" and hides it behind multiple layers of abstraction and no clean way to invoke for maintenance outside the normal boot framework.

Not the answer you're looking for? Browse other questions tagged .