Calling "service networking restart" kills unity
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unity (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Note: I am not sure if this is an issue with unity, with compiz, or with some other component such as dbus, or if it is multiple bugs.
At work I use a bridged network interface (br0) over eth0 on my laptop to seamlessly connect my laptop and its virtual machines to the corporate network. As Network Manager cannot handle bridged connections, I am forced to use the old /etc/network/
This setup worked fine in 12.04 and earlier versions. I was able to reconfigure the bridge (when necessary) and restart it using the command line without issue using those releases. When my computer is booted with the bridged configuration, 12.10 uses the bridge to connect to the network without issue. The problem occurs only when I restart networking.
In 12.10, issuing the command "sudo service networking restart" or "sudo /etc/init.
I have been able to replicate this consistently.
I am attaching my .xsession-errors file. Note that the entries up to and including line 110 were made before issuing the network restart command. Entries after 110 resulted from issuing the command.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: unity 6.8.0-0ubuntu2
ProcVersionSign
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
CompizPlugins: [core,bailer,
Date: Wed Oct 24 10:31:16 2012
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
SourcePackage: unity
UpgradeStatus: Upgraded to quantal on 2012-10-22 (1 days ago)
I did a test on another machine that has a more vanilla configuration with eth0 configured through Network Manager. The only thing in /etc/network/ interfaces was the loopback stuff that is installed there by default. I issued "sudo service networking restart" and the same thing happened: Unity essentially died and I had to switch to a virtual terminal to restart the computer. This result demonstrates that it is the networking script (or some hook program called by it) that is the problem, and not any particular network configuration.