Networking does not restart

This was never a supported way to bounce the network, starting with 14.04, we changed the init script to fail rather than possibly trash your machine.

If you look at upstart's log, you'll notice the following message:
Stopping or restarting the networking job is not supported.
Use ifdown & ifup to reconfigure desired interface.

There must be a better program output for such a backward incompatible behavior, not just in logs.

Er, I've been just bitten by this "feature" too.

Having the habit of using /etc/init.d/* (since it works on many different platforms and my fingers learned it many years ago) I presumed that would at some stage be replaced by the "service" command - but not that networking would be started in some different way.

So I would also agree with comment #2 :-)

This seems to be an unexpected change.

I appreciate the logic of the change but perhaps a more descriptive solution could be present in the error?

This is bad for remote administration over SSH. Running this command would allow you to cleanly restart networking remotely over SSH, now there is no nice way to do that.

ifdown <interface> and ifup <interface> works great, just use that. Restarting the whole network simply isn't possible when it's brought up through boot time events.

ifdown/ifup requires that every interface be detected before hand and restarted individually on multi-homed hosts and hypervisors.

For hypervisors in a cloud environment this includes virtual bridges as well. The init script method available till this release of the OS allowed restarting all interfaces and bridges on any host via a single command remotely. With this change, now each machine may need a different network shutdown/startup/restart process unique to its particular configuration.

I had the same problem in ubuntu 14.04. The following thread shows a workaround:

http://askubuntu.com/questions/230698/how-to-restart-the-networking-service?lq=1

sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a

This worked for me, restarted all interfaces except loopback.

@Stéphane I disagree, this is not possible to do remotely.

It sure is possible if you do it in the background. (ifdown blah ; ifup blah)& will work great.

Robert Taylor (rgtaylor) #7 is an important argument! Please reopen the Bug

"This was never a supported way to bounce the network..." <--- Not accurate

From https://help.ubuntu.com/10.04/serverguide/network-configuration.html
Now restart networking to enable the bridge interface:
sudo /etc/init.d/networking restart

From https://help.ubuntu.com/12.04/serverguide/network-configuration.html
Now restart networking to enable the bridge interface:
sudo /etc/init.d/networking restart

From https://help.ubuntu.com/13.10/serverguide/network-configuration.html
Now restart networking to enable the bridge interface:
sudo service networking restart

I have no control as to what's included in the server guide and in this instance the server guide is simply wrong.

ifupdown does not work if using virtualbox and machine has been cloned - including changing of MAC address during clone process...

Process..
Create new VM in VirtualBox 4.3.12
Install 14.04 server - 64
# sudo ifdown eth0 <- works
# sudo ifup eth0 <- works

Clone machine changing MAC address

# sudo ifdown eth0
# ifdown: interface eth0 not configured <- Output

Regardless of whether it's officially supported or not, the method did solve a lot of problems in one command. The only times it has caused issues for me is when I have tun devices created by other services. In general, I feel a better solution would be to have the networking only restart those adapters which it controls (seen in /etc/interfaces).

Can you point us to the discussion you had on a mailing list, or bug, or otherwise where it was discussed that this change needed to be made? Otherwise it seems like it was made by fiat and it's now 13 to 1 against.

Also I think the ifup/down are not used at boot time, so there are two different ways that the network gets setup.

It seems this was actually changed as of Ubuntu Saucy 13.10, as restart --system networking and /etc/init.d/networking both failed...

At this point, its faster/reliable to reboot my machine (10 seconds), than it is to open a terminal, and "ifdown --exclude=lo -a && sudo ifup --exclude=lo -a"..... init.d has always worked, including the many custom embedded Linux machines I develop for.

At least a better error message must be shown in the init.d output.

Where/when was this change discussed prior to the change?

I've added the following file:

/etc/network/interfaces.d$ cat lo1.cfg
auto lo1
iface lo1 inet loopback
        address 127.0.1.1
        netmask 255.0.0.0

How do I get it to take effect if not `restart networking`? I've tried `ifup lo1` but it just says cannot find device lo1. I have a feeling that I did `restart networking` before on a pre-trusty box and it worked.

"If you look at upstart's log, you'll notice the following message:
Stopping or restarting the networking job is not supported.
Use ifdown & ifup to reconfigure desired interface."
This error message should at least be visible in the standard output. "stop: Job failed while stopping" is really not very informative.

Anyway, ifdown & ifup do not work unless you configure the network manually:
ifdown: interface eth0 not configured

while ifconfig up & down do, so I would change the error message:
sudo ifconfig eth0 down && sudo ifconfig eth0 up

"This was never a supported way to bounce the network, starting with 14.04, we changed the init script to fail rather than possibly trash your machine."
This doesn't seem like a solution to me: it was not supported, but it was still working in many cases. Now it doesn't work, ever. Please at least provide a working alternative in a visible (i.e., not the log) error message.

Same problem here.

As mentioned by others, ifup/down it's not a real solution to restart interfaces (all interfaces), and it's strange to not have a real error message on stout.

I'm also using:

# (ifdown eth0 ; ifup eth0) &

man service suggests that "All scripts should support at least the start and stop commands. "

indeed this is a change of behavior that is quit crucial, even if "officially" service restart networking was never a "supported" way of doing it, it seems to be an intuitive way of doing so; simply because the script is there ! so intuitive that it is all over ubuntu documentations, really, a message that is more helpful is needed. otherwise, the mere existance of that script in the past should be considered a bug, and continues to be so ... i guess ....

#7 is not important, it's simply wrong.
man ifupdown, then complain.
For ifup it is enough that interface is present and configured in /etc/network/interfaces. Or you can just tell to start all configured interfaces.
For ifdown, you could always use -f.

VirtualBox argument is... just... I have no words. I'm laughing.

TL;DR: A bug report from someone, who never read, what system tell him, doesn't qualify as opinion. Much less a bug.

Echoing comment #15, please provide evidence that this was discussed somewhere, and why it was deemed important enough to castrate server admins. I just got bitten by it and ended up disabling networking on a server that's an hour's drive away. :-(

I just found this bug looking for a reason why my network failed to (re)start upon resuming from hibernation. Can this be related?

Server admins have been restarting networking with init scripts for many years, and for me personally it was rather disturbing to find this no longer works -- as well as to read some of the comments here. Networking that cannot be reliably restarted in the same manner it's brought up at boot time is a major problem. Luckily the init scripts from 13.10 actually still work, so this is my current workaround.

I'm not really sure what someone might do with networking that cannot be manipulated with ifconfig and other lower level commands, and therefore properly managed with init/upstart, but whatever warnings need to be applied, perhaps should be applied to whatever that is. And the fact that some networking devices/configs may not be reliably reloaded/restarted should not restrict the functionality of those that can.

In these various comments I've not heard a compelling reason one shouldn't be able to edit /etc/network/interfaces and restart/reload networking.

Ubuntu Server has been my distro of choice for several years for colo servers, vps's, vm's, etc.. Perhaps it's time to look at a different server distro..

This is totally unacceptable, please fix it and stop ignoring and denying the problem. Thank you.

This is clearly in need of a decent fix! The amount of scripts and systems this has broken for us is silly.

Turns out this was not the cause of failing network start after hibernation resume (see comment #26).

One additional problem is that, unless something radically happens to change the upstream, sooner or later the proper way to restart network will be to issue a `systemctl` command, because systemd.

So if now Ubuntu is abandoning the init script (controllable with the `service` command) in favor of ifup & ifdown, it is bound to break that again in the upcoming releases in favor of `systemctl`, unless as I mention the upstream changes mind or Ubuntu decides to stick with Upstart after all. Both seem highly unlikely at this point.

As for comments about breaking the connection with ifdown & ifup ... I don't get it, the init script does exactly that. So, what is broken, then?

I've opened 1382059 to suggest updating the server guide with the correct way to restart networking.

Bug 1382059 is duplicate with bug 1298505. The serverguide has already been fixed for 14.04. The bug remains open for the 12.04 serverguide, but is unlikely to ever be done.

This is ridiculous to see this is still an issue. I ran an update on a couple farms (that were staged in a lab). Now my networking scripts that I had *FIXED* are now overwritten... I now have 300+ servers that don't do anything with an init networking script. If this script is an issue, then please leave it out. The community will create their own patches. But more importantly, if this script was disabled purposefully (note the fix below) why was it overwritten by changes that don't do anything?

Can someone please post a link to where this decision was made? It's one thing if you want to disable this for desktops. It's an entire other issue for disabling for headless servers.

And why is there an init script that does nothing anyway? This makes no sense. An init script that sill exists I assume are "for legacy purposes" that is purposely broken? This is years in reverse to proclaim the OLD way for bouncing the network is now the "documented way." This breaks the motto of Ubuntu : Linux for Humans.

For those humans that still want to fix it (if you haven't done it already). Edit the script and go down to the arg switch... Comment out anything like the following...
       if init_is_upstart; then
               exit 0
       fi

Make it like...

# Why did you do this?
# if init_is_upstart; then
# exit 0
# fi

Yes, I, too, find this to be very frustrating! I need to be able to *easily* restart networking remotely via SSH and this is impossible with the new way of doing things. How can I help fix this?

This script must be fixed. For many years I've used it to restart network interfaces. Other distros have similar aproach too. Think in many scripts that was developed by system admins based on this functionality? IMHO, this is a very iimportant component that can't be excluded or ignored of a sudden. There is no reason to do that.

Before put this anwser, I've read the entire post and I've not see any plausible justification to disable the network script.

I know that some decisions must be unilateral for the benefit of all. But, this kind of decision, has a big impact and must be decided democratically with the entire community and needs to be grounded in a solid and concise justification.

This is my point of view and I believe, based on what I've read, is the same feeling of the majority.

Please, fix this.

Unreal!

Does anyone from Canonical understand the impact of this change?

This breaks any and all remote automation!!!!!

Please address this issue!

Just read this whole thread and I too am unable to find a good justification for why breaking this method of restarting networking was needed, or the aggregate benefit of breaking many many legacy scripts. Please resolve this!

I have changed my static ip configguration in /etc/network/interfaces.
But i was unable to use any of the command to bring my interface up and running. It's totally useless thing what i have found.
I tried the following options. none of them worked.
1. sudo /etc/init.d/networking restart
2. sudo ifdown eth0
3. sudo ifup eth0
4. sudo ifconfig eth0 down
5. sudo ifconfig eth0 up
but none of them reloads the /etc/network/interfaces

Seriously canonical... this is getting ridiculous... many High priority core functionality bus just being plain ignored...

In 14.10 I have network failure after resuming from suspension. It never was a problem then a few days ago it became a problem. The only solution was to reboot. So I looked for a better solution and tried them all. The one that works under 14.10 is:
                           sudo service network-manager restart

There are 6 other solutions presented in the Ubuntu forums here and there. If you needed to change it, you should have long ago created a script 'RestartTheNetworkingHoweverItNeedsToBeDone.sh' and changed that whenever you needed to change the underlying system.

hu! "Fix Committed "
Which package version fix this ?

Anyone have a link to where it was committed/released? Having trouble finding it...

Can someone tell me from where to find the new release??? I am not able to find that..

I too had huge problems with this issue. I have a 14.04 server blade that takes ages to reboot, but currently it is the only way to restart networking when adding for example network bridges.

This problem still exists. It is a feature regression. Stop denying that fact so it can be fixed.

In my brief testing it seems like sudo /etc/init.d/networking restart is working, but not sudo service networking restart.

No fix has been released. The status change must have been in error

Thanks for the update Simon.

Never mind /etc/init.d/networking restart does not work either. I tried removing an interface and then doing a network restart, but nothing took effect.

I would like to "officially" request escalation of this issue up to next level of Ubuntu support - it is currently listed as "confirmed", "high" and "unassigned". Ubuntu 10.04 LTS is very soon EOL, and this functional requirement is currently removed from the current LTS version with no migration path in place.

It has been flagged as a "hot" item for over a year and seems to be being ignored by Ubuntu development staff for what seems to be ideological reasons.

/etc/init.d/networking has been an essential method for anyone doing large scale headless server deployments to generically handle scripted network management of physical and virtual servers. In these environments, individual hosts could have completely different network interfaces on every individual machine. "Anyone", in this case also includes the authors of officially deployed deb application packages delivered with Ubuntu 14.04 that currently don't work...

This bug breaks cloud deployments of Ubuntu in Opennebula as delivered natively in deb's with Ubuntu 14.04. The network contextualization scripts delivered in opennebula-context_4.2.0-2_all.deb use "service networking" to dynamically assign virtual machines IP addresses on the fly at boot time. Without a fix, no Ubuntu 14.04 VM's running in an Opennebula Cloud can get an IP addresses - this has been the case since the OS version was released.

How many other network related applications are impacted by this change that were never tested for removal of this functionality?

As an organization that is focused on supporting virtualization and "cloud" server infrastructure (as opposed to only GUI desktops and phones), I would have expected development staff to have a better understanding of the impact of this type of issue and would have given it more attention than it has - or at least develop alternate functionality that meets the same functional requirements.

#last lines of /etc/one-context.d/00-network as delivered in Ubuntu 14.04 opennebula-context_4.2.0-2_all.deb
# ifup/down eth0 won't work - the virtual machine can have any number of dynamically assigned
# interfaces at boot time
...
"configure_network()
{
    gen_network_configuration > /etc/network/interfaces

    service networking stop
    sleep 1
    service networking start

    sleep 2
}"

I second rgtaylor's request. This additionally has great impact on automated build scripts & systems (in my case, Foreman/puppet) which need a way to make networking changes (such as new IP address) & apply those changes, often on systems for which console access is (at best) inconvenient due to location, etc.

The other serious technical issue is that with "networking restart" no longer supported either an init.d or upstart, there is no way to address automated restarting any of the dependent network services that would normally be restarted as a group (like nfs). Any automated build process is going to need to deal with configuration of not only the interface devices (ifup/ifdown), but also the restart of dependent network services to ensure that they are all updated with configuration changes (that's the whole purpose of init.d, upstart and systemd - to control the management and boot order of services and network dependencies, including the restarting of them).

I understand that Ubuntu is moving to systemd in future releases, but that isn't available in any of their current "LTS" releases and enterprise environments cannot move major infrastructure to another OS release that only has a 9 month support window. Ubuntu 14.04 LTS is going to be the major OS release used in enterprise environments till April 2019 - networking can't be left unsupported in both init.d and upstart until 16.04 comes out. With 10.04 LTS EOL shortly, this needs to be addressed rather than forcing enterprise institutions to update only to 12.04 LTS which expires in 2 years.

Please escalate this issue.

+1. This is a major inconvenience for deployment/operation of cloud infrastructure.

I can't believe this very important functionality has been removed and there is no alternative solution given for reading the /etc/network/interfaces file (except reboot)

Ifconfig solution doesn't read the configuration files. It is unacceptable.

There must be a script that reads this file. Where is it? How to trigger it?
Is it the same with debian?

This feature is documented everywhere:
http://ubuntuguide.org/wiki/Ubuntu_Trusty_Networking

As long as no viable alternative solution is given, this has to be considered a very important bug.

How is this still being ignored?? What is the work around? For example a bridge started and configured in /etc/network/interfaces errors when doing ifdown br0 as "not found" so this is obviously not a working method as previously noted.

+1. This is a major inconvenience. I had to restart the server every time for the nics to start working. (sad face)

This is unacceptable and disturbing change.
In Ubuntu 14.04 still work upstart and not systemd.

I don't see even one reason, why init script shouldn't work properly.
More than this, I don't see any reason, why there is no comment or warning when I use /etc/init.d/netwroking restart
Simply empty output. This is disgusting.

@booch, I am confused why you marked this as Invalid if you think that the script should work...

Almost definitely and accidental change to invalid

More than a year later and no action.. Unbelievable.

I made the mistake of attempting to deploy Trusty for a new DNS server. Spent about an hour attempting to migrate the old IP to the new box. None of the workarounds were successful -- including the 13.10 scripts the previously worked. Only rebooting the box brought the IP alias up successfully. Totally unacceptable.

Is this just something stupid in the scripts or is there some underlying change that actually broke networking?

If this isn't fixed soon, Precise will have been the last usable LTS server release.

Ugh.. All my Precise boxes will have to get migrated to some other distribution. Trusty is no longer an option..

+1 Please revert the script implementation back as it was when it was working. It affects too many of us. IMHO it is not a real improvement/feature when a script does nothing, better to remove it, at least it would be clear/clean.
Kindly

+1000

This is stupid

quote #50, and add request for escalation of this issue.

Quote #50
We need this bug fixed!

Any other solutions ? I am really looking for a clean solution to this.

I've been in IT a while, and this bug report is playing out in the standard dysfunctional way:

1. Obvious regression is made.
2. Developer states that the bug is a feature, that his/her way is the Correct Way, and that all other views are wrong or merely opinions.
3. Reams of evidence of material harm are proffered to the contrary.
4. Incredulous users hit by the regression keep piling on until (a) developers simply ignore the bug entirely forever, (b) a developer has public meltdown, (c) a more seasoned developer with the ability to consider diverging views steps in and resolves things.

I think we're all hoping for (c), but honestly, (a) is a vastly more common outcome.

The only thing missing is for someone to post "if you need this so bad, just fork the distro yourself...that's the open source way!", as if someone's going to actually develop "Non-broken-networking-buntu".

This is my current workaround patch, which seems to work fairly well:

sed -i 's/if init_is_upstart/if false \&\& init_is_upstart/ig' /etc/init.d/networking

Simply changes all instances of "if init_is_upstart" to "if false && init_is_upstart".

great... due to that "feature" i just lost a day of precious working time and had to drive almost 100 miles for nothing. following this thread to find out why /etc/init.d/networking restart not working anymore (and causing lots of unwanted effekts and in the end lost connectivity ) to find out that some people are really ignorant enough to still call this change of expected behaviour which worked very well for years and years a "feature" and "it was never intended to blahblah".
--> have you guys gone crazy??

this is BULLSHIT and you should fix it right now and restore this functionality
(BTW you messed up big with changed DNS syntax as well... really funny changing important stuff all the time and waste precious time of countless people who try to get stuff running... right??)

8.04 LTS worked (and still works) for years, was the most stable distro of all times in my 20 years career
12.04 LTS worked well, recently lots of problems, repositories not found, lot of manual work... not good
14.04 LTS lots of annoying problems and "features" that will drive many people away from a once good distro

I would boot the people with that "extra creativity", restore reliability and make stuff working again, if you guys have a rest of decency than you say "sorry we messed this up big and we gonna fix it now"

The man hours lost on this across the globe are rising. The sudo ifdown eth0; sudo ifup eth0 solution solves some of the problems but not all of them.

Either way, a better error message would be helpful in at least saving people from debugging why it doesn't work and then coming in here and ranting.

Summary of this thread:

Sysadmin: "Dude, I've been using hammer (tm) since 1.0, and it always had a handle. Now in 14.04 all I get is the hammer head, what gives?"

Vendor: "Using the handle was never supported."

Sysadmin: "So, like, what am I supposed to do when I need to hammer in a nail?"

Vendor: "Just hold the hammer head in your hand and hit the nail. What seems to be the problem?"

<mutually incomprehending stares>

hello,everybody
I also meeting this question or said BUG.
begin,i can`t telnet my linux in the VMware 11.0,I find ways to restart net,
I read your comments and I have some thinking.
end,I find gateway is wrong......

I fixed my question but bash still echo
$sudo service networking restart
stop :Job failed while stopping
start:Job is already running :networking

welcome send me E-mail to discuss about linux and make friends.
<email address hidden>

This is affecting me as well. I don't care about the bug/feature argument, but I know other folks are running into this in Puppet managed environments. Has anyone come up with a graceful workaround for the following:

class networking {

    file { 'interfaces':
        source => 'puppet:///modules/networking/interfaces',
        path => '/etc/network/interfaces',
        notify => Service['networking'],
    }

    service { 'networking':
        ensure => 'running',
        enable => 'true',
    }

}

Off the top of my head a solution that requires running ifdown followed by ifup would require the use of 2 exec types in a specific order. I'm far from a Puppet expert, but I know that this would be fairly complex to code and quite error prone.

Any help would be appreciated. I know that many of you are volunteers and I appreciate the time and effort you put into making Ubuntu a great distribution.

The command in comment #8 *should* do this in a single exec resource:

sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a

However, I have found this does not actually work either for any significant config change (e.g. IP address change, gateway change). In fact, the command above frequently causes networking to stop working in such cases.

The only way I've found that works is to reboot the server; NetworkManager is not an option when doing text-based network config. Other distros using upstart do not seem to have this problem. It's a shame that Canonical hasn't seen fit to address this, and its cost them my employer's (albeit meager) support budget.

This is another sign of a good distribution going backwards.

I need to change a large VM cluster from DHCP to static over SSH using automation tools

/etc/init.d/networking restart used to work remotely for this. What the heck am I supposed to do now?

Clearly everybody used /etc/init.d/networking . Can it not be retrofitted to be a supported function?

Can anybody confirm a method of reliably reloading the network config remotely over SSH ?

This does not work for me.

 ifdown eth0 && ifup eth0

as root, running over ssh and screen and the machine has disappeared.

Unfortunately our test machines are not VMs with local access only to the console.
I now have a long round trip journey to the datacenter.

What a waste of time. FFS

Is there really no better solution for this than ifdown/ifup ?

What is the recommended method to restart all networking services, rather than a select interface?

RHEL can manage this easily: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-NetworkManager_and_the_Network_Scripts.html

"Although NetworkManager provides the default networking service, Red Hat developers have worked hard to ensure that scripts and NetworkManager cooperate with each other. Administrators who are used to the scripts can certainly continue to use them. We expect both systems to be able to run in parallel and work well together. It is expected that most user shell scripts from previous releases will still work. Red Hat recommends that you test them first."

What is the equivalent for Ubuntu / Canonical?

#74: Good point!

Stéphane Graber (stgraber) is not subscribed to this bug anymore and this bug is unassigned. I fear that #64 point a) has happened for real. Hmm...

At the same time an officially supported way to restart the interfaces reliably, even over SSH, is missing. My only hope is that this will be implicitly resolved in 16.04 when migrating to systemd.

'networking restart' was found to be able to to break some GUIs, as reported here:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1072518

Apparently '/etc/init.d/networking restart' was bringing down entire desktop environment (obviously on desktop version of OS). It was reported for Ubuntu >=12. Also I've noted that the people there where mentioning frequently also Network Manager, so I can imagine that some faulty link between some GUI component and networking was introduced, which may lead under certain conditions to a crash (pls correct me if you went further in this investigation). So, disabling of networking restart seems to be quick workaround to overcome some bigger problem in GUI. Do not ask me why to do the same for the server OS.

I can imagine that with introduction of Unity desktop (exactly starting from Ubuntu12) which is purely 'consumeristic' with all its blinking, jumping, scrolling semitransparent stuff, they did not manage to keep anymore well separated GUI from key system functionalities...

I'm personally using Ubuntu 12 Server with Gnome 3 traditional GUI (w/o Network Manager) on my laptop for several years already, and '/etc/init.d/networking restart' did never brake my system. I'm running Ubuntu 12 server at several servers, and did never get trouble with networking restart. I've recently installed Ubuntu 14 server + classical Gnome 3 on one desktop, and after adjusting /etc/init.d/networking as suggested by Joshua (#33), and restarted it several times after - nothing bad did happen to the desktop GUI...

It seems to be rather sad trend in OS developing when faults in GUI determines future of server OS. I want to believe that in the next future we will not need to reboot after every change in configs of Cups, Samba, Apache... Like one should do in Windows.

Why hasn't this been fixed yet. It's a total automation fail.

If I understand correctly, this won't be fixed at this level. Some sort of
escalation would need to happen to put the facts in front of someone else
to get a different decision.

On Tue, Mar 29, 2016 at 10:41 AM Dennis DeMarco <
<email address hidden>> wrote:

> Why hasn't this been fixed yet. It's a total automation fail.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1301015
>
> Title:
> Networking does not restart
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1301015/+subscriptions
>

I just stumbled into this issue, somehow missed it till now. Wanted to setup 14.04 as my Puppet enterprise Master but will have to use Centos 7 as the service provider for puppet uses 'service X restart'

at least version 15 has systemd startup, none of this ifup, ifdown nonsense

This is a problem for bonded interfaces. A full networking restart is required when reconfiguring slave interfaces or bonds. The lack of support for restarting networking then means a full host restart is required, which is absurd. This isn't Windows.

Seriously people, get over yourself. Here's what the init script did on restart:

  ifdown -a --exclude=lo $verbose
  ifup -a --exclude=lo $exclusions $verbose && ifup_hotplug $exclusions $verbose

All the rest is message output, checking for /etc/network/options and other boilerplate stuff. That's exactly the same suggestion feliperechia made in #8 about 2 years ago.

"Oh, but he didn't mention ifup_hotplug or $exclusions yadda yadda"

Well, ifup_hotplug actually extracts a list of interfaces from the output of `ifquery --list --allow=hotplug`, checks they're physical interfaces and have physical link, and runs ifup for all of them.

I sincerely doubt any of the "oh I screwed up and now have to take a 4 hour flight to the datacenter" are hotplugging their network interfaces. If your NIC is available on boot it should be set to 'auto' and will be picked up by `ifup -a`. No need for ifup_hotplug on headless servers.

$exclusions is the EXCLUDE_INTERFACES parameter from /etc/default/networking. $verbose is either '-v' or empty. You probably don't use either.

So yeah, `( ifdown -a --exclude=lo; ifup -a --exclude=lo) &` should work for everyone because that's exactly what `/etc/init.d/networking restart` did.

Can we move along now? Thanks!

>Seriously people, get over yourself

There's no need to be rude and condescending, Gabriel. It is possible to have a disagreement without being a jerk about it.

There's about 100% more keystrokes in:
> `( ifdown -a --exclude=lo; ifup -a --exclude=lo) &`
vs
> service networking restart

Plus `service networking restart` is much cleaner, easier to type, memorable, and baked into a considerable number of people's scripts. So no, we can't move along. This is the definition of a regression, and it's clear why so many people are bothered by it.

Additionally, the ifdown/ifup method does not load certain changes (e.g. IP address) properly, and often breaks networking when such changes are made.

+1 (#27 and alike)

On 16.04 I have to do as follow to make new IP work after modify the file /etc/network/interfaces, cause `service networking restart` not work.

```
sudo if addr flush eth0
sudo ifdown --force eth0
sudo ifup eth0
```

On 16.04 I have to do as follow to make new IP work after modify the file /etc/network/interfaces, cause `service networking restart` not work.

```
sudo ip addr flush eth0
sudo ifdown --force eth0
sudo ifup eth0
```

Ubuntu 14.04 Server Not Rebooting (ifupdown network issue)

It appears that with the latest bundle of Ubuntu updates, ifupdown breaks the server boot quite fantastically.

Resolution 1: Change the order that the updates are applied in

[1] BACKUP SERVER!
[2] apt-get update
[3] apt-mark hold ifupdown
[4] apt-get upgrade -y
[5] apt-mark unhold ifupdown
[6] apt-get upgrade -y
[7] Check that the server reboots correctly

Resolution 2: edit your network interfaces file, specifically looking for incorrect commands:
example: post-up ip6tables-restore < /etc/iptables.up.rules

This is clearly not correct since it is attempting to load IPV4 tables to IPV6 routes and will result in a network failure,
thus preventing booting of the server.

[1] nano /etc/network/interfaces
[2] Remove incorrect post boot commands, ie. post-up ip6tables-restore < /etc/iptables.up.rules
[3] apt-mark unhold ifupdown (If you previously had the package on hold)
[4] apt-get upgrade -y
[5] Check that the server reboots correctly.

I am not sure where this bug came from @ubuntu but it is nasty, nasty, nasty!