Gutsy network-manager causes OS to freeze on system restart or power down

Bug #183568 reported by Lhorz
4
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: network-manager

Using ubuntu 7.10 Gutsy Gibbon

Dell Optiplex 620
Radeon x1350 family graphics card
Proprietary ATI drivers for the graphics card
Broadcom GB network card
Wired ethernet

Reproduction Steps:
Start OS,
Log into the gnome gui
Click the red button in the upper right hand corner
Select restart from the popup menu.

The ubuntu power-down splash image will appear
The ubuntu power-down splash image will disappear & be replaced by the command line

The system halts - the following is the last message
Network Manager: nm_dbus_device_signal_status_change: assertion 'cb_data -> data -> dbus_connection' failed

This problem can be reproduced by selecting power down rather than restart in the gui.
It can also be reproduced by performing
sudo shutdown -r now
at the command line.

Cross reference the following thread on the ubuntu forums:
http://ubuntuforums.org/showthread.php?t=584652

The forum suggested several workarounds:
add reboot=b in /boot/grub/menu.lst
this didn't work.

Alternate workaround
add
deb http://wicd.longren.org gutsy all
to software sources
use the synaptic package manager
uninstall network-manager & network-manager-gnome
install wicd

This workaround was successful for my configuration, however it is sub-optimal.
It looks like development on wicd stopped around the time of edgy eft.
wicd appears to be optimized for wireless rather than wired networks.
following the instructions for autoconnect on system startup leads wicd into an endless loop.

I reverted back to network-manager and just hope that this bug gets fixed soon.
I don't have to power down this system that often. Right now, when I have to
power down, I do a hard reset using the power button on the front of the machine.

Revision history for this message
CalvinMcGee (joachim-nyqvist) wrote :

I have exactly the same problem. It is really annoying. Have anything happened with this bug?

Revision history for this message
Lhorz (hilarionl) wrote :

Calvin,
To the best of my knowledge there has been no progress on this bug. I had to update the linux image on my machine this morning; the update required a system restart. As usual, I had to do a manual power down to get out of the restart freeze.

Some of the related bug threads suggested that this is a pretty low level bug related to various hardware configurations. I'm not convinced of this interpretation because I was able to eliminate the bug by uninstalling network manager.

Are you using a wireless card for connectivity? If so, I might recommend that you use wicd as a workaround. I confirmed that replacing network-manager with wicd eliminates the problem. However, I've got a wired connection & wicd is optimized for wireless, so it wasn't a very good fit for me. I reverted to network-manager.
-Larry

Revision history for this message
Martin Fuzzey (mfuzzey) wrote : WORKAROUND: Re: Gutsy network-manager causes OS to freeze on system restart or power down

The problem appears to be caused when network manager catches the SIGTERM (15) signal
I have a workaround involving hard killing network manager with SIGKILL:

Modify /etc/dbus-1/event.d/25NetworkManager as follows (just add the --signal 9 option)

d_stop() {
        # Modified MF 11 Feb 2008 To avoid NM hang
        #start-stop-daemon --stop --retry 60 --quiet --pidfile $PIDFILE \
        # --oknodo --user $USER --exec $DAEMON

        start-stop-daemon --stop --signal 9 --retry 60 --quiet --pidfile $PIDFILE \
                 --oknodo --user $USER --exec $DAEMON
}

Modify /etc/init.d/sendsigs as follows
...
        # Kill all processes.
        log_action_begin_msg "Terminating all remaining processes"

        # Added MF 11 Feb 2008 To avoid shutdown hang
        OMITNM=
        if [ -f /var/run/NetworkManager/NetworkManager.pid ]; then
                OMITNM=$(cat /var/run/NetworkManager/NetworkManager.pid)
                OMITNM="-o $OMITNM"
        fi
        echo "Not killing $OMITNM"

        killall5 -15 $OMITPIDS $OMITNM

        # END MF mods
        log_action_end_msg 0
...

Revision history for this message
Martin Fuzzey (mfuzzey) wrote : INVESTIGATION Re: Gutsy network-manager causes OS to freeze on system restart or power down

Some more details on my setup and investigations.
The problem is 100% reproducable for me on a Dell Latitude D520.
I have narrowed it down as follows:

Boot machine then switch to text console before logging in
Login in text mode as root

/etc/init.d/gdm stop
/etc/dbus-1/event.d/26NetworkManagerDispatcher stop
shutdown most other services (ps -ef output showing processes remaining in attached file)

strace -p <PID OF NM> -f 2> /var/log/nmstrace.log &

do a ALT-SysRq t to dump kernel threads before hang to syslog

kill -15 <PID OF NM>

system now hangs after a couple of seconds:
No more console echo
Cannot switch virtual consoles
Cannot connect or use existing SSH sessions
Cannot ping machine

do another ALT-SysRq t to dump kernel threads after hang to syslog
ALT-SysRq s (sync disks)
ALT-SysRq b (reboot)

Attached is an archive with the logfiles from all this.

Revision history for this message
Lhorz (hilarionl) wrote :

I've implemented the workaround suggested by Martin Fuzzey on Feb 11 2008 involving editing
/etc/dbus-1/event.d/25NetworkManager
/etc/init.d/sendsigs

I've confirmed that the workaround is effective in eliminating the OS hang on restart.

Revision history for this message
Leszek (bigl-aff) wrote :

I can confirm that workaround suggested by Martin Fuzzey on Feb 11 2008 works.

But I've found much simpler woraround which works for me - I swich my wired connection from roaming mode to DHCP. With such configuration I've no delays on shutdown/reboot.

Revision history for this message
Lhorz (hilarionl) wrote :

I can confirm that the workaround suggested by Leszek on April 19th is also effective at eliminating the OS freeze on restart.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.