Restart networking crashes dbus and the desktop manager

Status changed to 'Confirmed' because the bug affects multiple users.

Same occurs with:

sudo service networking restart

All running apps including the panel are closed. The terminal window from where the command was launched remains visible but is unresponsive. As reported by tbys, the only recovery I have found is to drop to a non graphic tty and reboot.

This is on a 2012 MacBook Pro i7 with wired network and no wireless:

Linux MacBuntu 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

This is also a big problem for me.

Using ubuntu 12.10 i386 and amd64, both fully updated final releases, both are affected both have very different hardware.

I have gnome-shell installed but it also happens in the unity desktop too!

I have been unable to simply restart gnome-shell as it either reappears with no window manager again or locks up trying to start it again.

I have to ultimately reboot the computers to recover, very tedious and annoying, let me know if I can help with debugging this and finding a fix.

Cheers Swampy.

I don't know if this helps, but here is a stacktrace from unity when the crash happens:

$ unity --advanced-debug
Starting program: /usr/bin/compiz --replace
[...]
Program received signal SIGTERM, Terminated.
0x00007ffff727a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Arquivo ou diretório não encontrado.
#0 0x00007ffff727a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        resultvar = 0
        pid = <optimized out>
        selftid = 4035
#1 0x00007ffff3b60bb8 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
No symbol table info available.
#2 0x00007ffff3b605c0 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
No symbol table info available.
#3 0x00007ffff4bd012b in g_cclosure_marshal_generic_va () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#4 0x00007ffff4bcf407 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff4be7df6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#6 0x00007ffff4be8642 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#7 0x00007ffff199feb5 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
No symbol table info available.
#8 0x00007ffff5b8cab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#9 0x00007ffff5b8cde8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#10 0x00007ffff5b8d1e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#11 0x000000000040270b in main ()
No symbol table info available.

same happens on current image of 13.04 i386 desktop live environment right after restarting networking service, so basically in my case steps to reproduce look like this:

1. --2013-03-04 16:19:34-- http://cdimage.ubuntu.com/daily-live/current/raring-desktop-i386.iso (gmt +3)
2. boot into system
3. get into another terminal (ctrl+alt+f1)
4. sudo service network-manager stop
5. sudo service networking restart

gnome-settings-daemon segfault occurs according to syslog:
Mar 4 17:29:19 ubuntu kernel: [ 302.709872] gnome-settings-[3658]: segfault at 8 ip b3e336b1 sp bff56430 error 4 in libpower.so[b3e23000+19000]
Mar 4 17:29:21 ubuntu gnome-session[2997]: WARNING: Application 'gnome-settings-daemon.desktop' killed by signal 11
Mar 4 13:39:10 ubuntu gnome-session[2997]: WARNING: Could not connect to ConsoleKit: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

Same here. It also crashes my network connection and I have to reboot manually with sudo reboot.
I don't need to go to a virtual terminal though. My xterminal comes back (with a different background color) and I can issue the reboot command.

/etc/init.d/networking stop is supposed to bring down your network
interfaces. It's not crashing your network connection, it's doing what it's
supposed to. The bug we're talking about is that it also brings down your
display manager, which it's not supposed to do. After you issue the stop
command, you can start your networking back up by /etc/init.d/networking
start
On Mar 21, 2013 12:40 PM, "paolo schiattarella" <
<email address hidden>> wrote:

> Same here. It also crashes my network connection and I have to reboot
> manually with sudo reboot.
> I don't need to go to a virtual terminal though. My xterminal comes back
> (with a different background color) and I can issue the reboot command.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1091399).
> https://bugs.launchpad.net/bugs/1072518
>
> Title:
> Restarting network crashes (apparently) the desktop manager
>
> Status in “ubuntu-meta” package in Ubuntu:
> Confirmed
>
> Bug description:
> The unity UI and windows decorations dissappear when I do one of the
> following:
>
> sudo restart networking
>
> or
>
> sudo /etc/init.d/networking restart.
>
> This renders me unable to focus any of the open windows with
> mouse/keyboard, leaving the system unusable. I have to drop to
> terminal (CTRL-ALT-F2) and do a sudo reboot.
>
> I am not sure what parts of the desktop are going down, so I posted
> this bug under ubuntu-desktop. I'd be happy to follow up with more
> information as needed.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.10
> Package: ubuntu-desktop 1.287
> ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
> Uname: Linux 3.5.0-17-generic x86_64
> ApportVersion: 2.6.1-0ubuntu6
> Architecture: amd64
> Date: Mon Oct 29 09:45:12 2012
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2012-10-20 (8 days ago)
> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64
> (20121017.5)
> MarkForUpload: True
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: ubuntu-meta
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1072518/+subscriptions
>

I had that same problem, it would crash each time I tried to restart the network-manager. Finally I restarted it from the root and it worked, afterwords I could restart for any user, but for some reason the changes that i had made in interfaces did not show up when executing the command: ifconfig. Hopefully this helps a bit.

gnome-settings-daemon indeed crashes in that case, which breaks a load of things, including the desktop manager in general.

The reason for this is that when you restart the networking job, it kills off the system dbus bus, which brings down quite a lot of stuff with it.

If you're looking to restart network-manager, you'll want to do 'sudo restart network-manager', not 'sudo restart networking'.

If you're making changes to /etc/network/interfaces, running "ifup -a" will usually suffice to apply the changes. (or you can "ifdown <interface>", then "ifup <interface>".

Hey, thanks for the tip, but we still need a proper solution. Why is dbus
brought down when networking stop is called?
On Apr 5, 2013 3:41 PM, "Mathieu Trudel-Lapierre" <email address hidden>
wrote:

> If you're looking to restart network-manager, you'll want to do 'sudo
> restart network-manager', not 'sudo restart networking'.
>
> If you're making changes to /etc/network/interfaces, running "ifup -a"
> will usually suffice to apply the changes. (or you can "ifdown
> <interface>", then "ifup <interface>".
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1091399).
> https://bugs.launchpad.net/bugs/1072518
>
> Title:
> Restarting network crashes (apparently) the desktop manager
>
> Status in “gnome-settings-daemon” package in Ubuntu:
> Confirmed
>
> Bug description:
> The unity UI and windows decorations dissappear when I do one of the
> following:
>
> sudo restart networking
>
> or
>
> sudo /etc/init.d/networking restart.
>
> This renders me unable to focus any of the open windows with
> mouse/keyboard, leaving the system unusable. I have to drop to
> terminal (CTRL-ALT-F2) and do a sudo reboot.
>
> I am not sure what parts of the desktop are going down, so I posted
> this bug under ubuntu-desktop. I'd be happy to follow up with more
> information as needed.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.10
> Package: ubuntu-desktop 1.287
> ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
> Uname: Linux 3.5.0-17-generic x86_64
> ApportVersion: 2.6.1-0ubuntu6
> Architecture: amd64
> Date: Mon Oct 29 09:45:12 2012
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2012-10-20 (8 days ago)
> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64
> (20121017.5)
> MarkForUpload: True
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: ubuntu-meta
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1072518/+subscriptions
>

the same problem with:
Linux ginetto-tablet 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:20:06 UTC 2013 i686 i686 i686 GNU/Linux
what data do you need to be helped to solve?

It's just the way things are done for the shutdown procedure.

As I mentioned above, you shouldn't need to run "restart networking" (in fact, it probably needs to be renamed to something else to avoid confusion), using ifdown and ifup to bring up and down network interfaces directly will do the right thing and avoid stopping dbus.

How does networking -stop differ from killing dbus? If for the sake of
argument I wanted to stop dbus without sigkilling it, how would I do that?
And how would I bring down all of my ifaces at the same time without
writing another script, which would bring them down sequentially at best?
This last one is in the scenario that I have a box set up as a router or
load balancer.
On Apr 9, 2013 3:35 PM, "Mathieu Trudel-Lapierre" <email address hidden>
wrote:

> It's just the way things are done for the shutdown procedure.
>
> As I mentioned above, you shouldn't need to run "restart networking" (in
> fact, it probably needs to be renamed to something else to avoid
> confusion), using ifdown and ifup to bring up and down network
> interfaces directly will do the right thing and avoid stopping dbus.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1091399).
> https://bugs.launchpad.net/bugs/1072518
>
> Title:
> Restarting network crashes (apparently) the desktop manager
>
> Status in “gnome-settings-daemon” package in Ubuntu:
> Confirmed
>
> Bug description:
> The unity UI and windows decorations dissappear when I do one of the
> following:
>
> sudo restart networking
>
> or
>
> sudo /etc/init.d/networking restart.
>
> This renders me unable to focus any of the open windows with
> mouse/keyboard, leaving the system unusable. I have to drop to
> terminal (CTRL-ALT-F2) and do a sudo reboot.
>
> I am not sure what parts of the desktop are going down, so I posted
> this bug under ubuntu-desktop. I'd be happy to follow up with more
> information as needed.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.10
> Package: ubuntu-desktop 1.287
> ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
> Uname: Linux 3.5.0-17-generic x86_64
> ApportVersion: 2.6.1-0ubuntu6
> Architecture: amd64
> Date: Mon Oct 29 09:45:12 2012
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2012-10-20 (8 days ago)
> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64
> (20121017.5)
> MarkForUpload: True
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: ubuntu-meta
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1072518/+subscriptions
>

Happening to me as well. I have a thread opened on ubuntuforums as well
http://ubuntuforums.org/showthread.php?t=2139490

I have the same problem with 13.04.

the same problem with:
Linux fernando-pc 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

# is a critical issue as well as impossible to configure the network in the shell

Same behavior for gnome-shell in 13.10.

The same on Unity on 13.10 ( like this since 13.04 )

Came to the same result, when i tried to set up kvm networking. https://help.ubuntu.com/community/KVM/Networking recommends to stop networking, i did, and swooosh, everything is gone. :-) Yay!

The issue is not a desktop/unity/gnome-settings-daemon/... one, restarting the network that way shouldn't be down (it takes down the dbus system bus which makes basically most modern softwares unhappy). Why are you using that command?

Hi thread.

Sebastien, personally, I attempted to use that command several times already with the intent to reset my networking subsystem state. Because of some other bug, my system stops resolving hostnames at some point, and redoing the connection is the easiest way to make network operational again. And oftentimes, the simple CLI command is more accessible than half a dosen clicks.

In short: I want to `restart networking` simply because I've restarted each and every service out there, and it was always fine. At least, it never ended up in any loss of my working data. As a bonus, `restart <anyservice>` restarted *only* the service requested, not the whole desktop session.

So, either the manual invokation of `/etc/init.d/networking restart` should require an interactive confirmation (with appropriate warnings about data loss), or even reject the command altogether. Or alternatively, if the `networking` service doesn't represent the networking subsystem itself, then it should be renamed. Or, if it does, then the question shall be answered: what's the bloody business networking subsystem has to do with DBus system bus?

Definitely can confirm this issue. sudo service networking restart completely destroys my window session with the only option left forcing shutdown on tty1. Breaks 13.10 for me as I'm constantly re-configuring my interfaces.

I'm interested to know where Mathieu Trudel-Lapierre (mathieu-tl) and Sebastien Bacher (seb128) get their information. If that is the case that it brings down dbus (and is supposed to bring down dbus), then I should see my desktop crash whenever I run this command on whatever machine I run it on? That is not what is happenning though, it occurs on only one particular computer of mine. Also, if this were the case, then why would running this command be recommnded in thousands of places, often as a final step after making changes to your web stack. Restarting any service shouldn't screw over your system, and I mean absolutely any service. If restarting it does that, then it shouldn't have a restart option, should have to manually kill it. If it needs to bring down dbus, then it should also bring it up again, in a smooth problem free way. Anyway, if the two of them are right and the command shouldn't be run, then this is probably one of the largest disconnects I've ever seen between the people that wrote a program and the people that make use of it.

+1 for a solution to this bug. Crashes Xubuntu 13.10.

I have the same problem restarting the networking service (sudo service networking restart) crash my desktop
Usign Ubuntu 13.10

Same problem here on 12.10.

I restart networking because this is given as way to make Wifi working: http://ubuntuforums.org/showthread.php?t=202834

Reported issue to freedesktop as they maintain dbus

At Simon McVittie's suggestion (from dbus @freedesktop.org) and reding some of the comments from the bug duplicates of this bug. The general thought is that the Upstart/Sysvinit conflict may lie at the root of this issue. Since 2 Ubuntu LTS releases ago, the dev's decided to use Upstart for the system init. Upstart is meant to be a complete replacement for Sysvinit. In the interest of backwards compatibility, the Upstart devs made some allowances so that people/packages still using sysvinit-style init scripts could continue to do so. The /etc/init.d/networking init script is written for sysvinit in such a way that calling it uses sysvinit methods and breaks dbus which is written for Upstart.

The solution here is to have the maintainer of the networking init script fix/rewrite it so that it is Upstart compatible. This may mean that the networking init script will lose compatibility with sysvinit, but they need to get over it. Sysvinit is deprecated/obsolete and too much effort is being wasted into maintaining it when the future is Upstart. And especially because Ubuntu's official init is Upstart, it would make sense to make it work with this package rather than a past one.

Eventually, when sysvinit is long dead, there will be no need for init scripts as Upstart does not need them, but fixing the current script is a good place to start.

/etc/init.d/networking is contained within package initscripts which is part of the sysvinit package which is maintained by the Ubuntu Core Developers mailto:<email address hidden>

Multiple users affected

I don't believe that this has anything to do with an "upstart/sysvinit conflict". The problem is simply that "restart networking" is not a sensible thing to do on a desktop system.

@Bryan Gonzalez:
Upstart is not the future any more, systemd is:
http://www.omgubuntu.co.uk/2014/02/ubuntu-debian-switching-systemd

Restarting the networking subsystem is not a task that a user would need to complete on a regular basis. I grant you that. However, there are a few times that this is necessary and it is not acceptable to respond: a) "don't perform said task" or b) "perform it using another command X"

The problem is that we have a method to perform this task that is tried and tested for many years. If the functionality is defunct, then it needs to be removed so that all the content online can be updated so that new users are not confused. OR The functionality needs to be updated to work with the current programs.

Inaction is not an option. It's against the creed.

@Vincas
Thanks for the information. I had not read about the formal decision. However, you are still agreeing with me that sysvinit is deprecated. So whether it's for Upstart or Systemd, the existence of the now defunct networking init script still needs to be addressed since for the forseeable future, 14.04 LTS included, we will still be using Upstart. SRC: http://www.markshuttleworth.com/archives/1316

@Steve
I'm surprised. I just got done reading https://wiki.debian.org/Debate/initsystem/upstart which indicates you are the position maintainer. I was actually referring to this debate without directly quoting it. So I can see how this bug strikes a nerve with you. But debating aside, the issue (the networking init script) still needs to be addressed. My preference is to fix the script so that it works correctly with Upstart, for as stated above, we will still be using it for some time.

Also, I forgot to mention: Simon McVittie over on freedesktop confirms that both

/etc/init.d/networking restart

and

restart networking

function as expected (correctly, no crashes) in Debian with systemd. So this observation adds to why I think it's an upstart or sysvinit issue.

@xnox "sudo service network-manager restart" and "sudo service network-interface restart" both crash dbus too. Is it related to Upstart or Systemd?

Here is updated patch to prevent configuring new interfaces upon calling stop networking / restart networking.

@ ivan-kukobko
This "sudo service network-manager restart" does not crash dbus.
This "sudo service network-interface restart" makes no-sense, as no instance is specified and it's an instance job.

Please file separate, new bugs for any issues that you have. And let developers responsible for these component to triage them appropriately.

@ bgonza868
Read the job, and look at the events. As it stands now, stopping (or restarting networking service) is intended to only happen during shutdown. As all network interfaces are deconfigured, all network filesystems are unmounted, system dbus is stopped, all graphical user sessions are killed, network-manager/bluetooth/avahi/ofono are all stopped. This is why networking job is only supported to be started on boot, and stopped on shutdown. There is no logic to support interactive stopping or restarting this job in Ubuntu. This has nothing to do with freedesktop, other operating systems, other upstream projects, syvinit, upstart or systemd. This is purely what networking.conf upstart job supports doing as shipped in the ifupdown package in ubuntu today.

@Dimitri Thanks for the patch. This was all about tying up loose ends. Many unofficial resources on the web and some official ones too explicitly direct users to directly invoke that particular script. Which, if you are not in the loop, as I was and apparently another 119 users were, will lead you to inadvertently crashing your system. This was a left-over deprecated functionality that though 'everyone knows no to use it' will cause damage if used. As you eloquently put it, this functionality no longer has any practical use, therefore it needed to be pruned. Again I thank you.

Many tend to forget that Ubuntu's vision is to be the OS for humans. In many ways it has achieved this, but there is still room to improve. You'll find that for many people, Ubuntu is the first non M$ and non Mac OS that they ever experience, making it an excellent learning platform for people. So even though there is a wide gap between gui users and cli users, you'll find a large group somewhere in-between. So that's why it was so important to me to have this issue resolved. If a function is useless yet still carries the potential for harm, then there is no reason for it to exist. So thanks for your assistance.

This bug was fixed in the package ifupdown - 0.7.47.2ubuntu2

---------------
ifupdown (0.7.47.2ubuntu2) trusty; urgency=medium

  [ Stéphane Graber ]
  * Allow setting the MTU and HWADDR on manual interfaces. (LP: #1294807)
  * The above change also means that manual interfaces will now be
    brought up and down (ias many users expected until now).
  * Disable link.defn as it's not covering all the cases supported by
    the vlan and bridge hooks and so causes more harm than good at this
    point. (LP: #1295304)
  * Also enable network-interface-container for OpenVZ. (LP: #1294155)
  * Update networking.init to exit 1 on reload when on an upstart system.
  * Pass --force to ifdown in network-interface to silence errors on
    non-existing interfaces. (LP: #1295620)

  [ Dimitri John Ledkov ]
  * Prevent the ability to stop or restart networking service
    interactively. As that is not supported. Networking job is only stopped
    during shutdown sequence. (LP: #1072518)
 -- Stephane Graber <email address hidden> Wed, 19 Mar 2014 18:04:49 -0400

Now you got a broken system. How can I bring down all interfaces at once now? If I have network-manager enabled is nm who controls the interfaces and the ifup/ifdown scripts don't to their work. Now I have to take my hands out of the keyboard to move the mouse to the up right corner of the screen.

And you call this "GNU/Linux for humans". If it is for humans it must be for all kinds of humans and do it easier and quicker to manage. Now you've slowed me and other people down.

If there's a way to restart all interfaces at once while I'm using a terminal please tell me.

Please see bug 1430934 for this issue under systemd.