Bug 441596 - NetworkManager disables wired ethernet at log out, before login
NetworkManager disables wired ethernet at log out, before login
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On: 385821
  Show dependency treegraph
Reported: 2008-04-08 17:21 EDT by David Timms
Modified: 2008-10-11 16:19 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-11 16:19:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
var/log/message indicating NM trouble bzip2ed (66.02 KB, application/octet-stream)
2008-04-28 18:50 EDT, David Timms
no flags Details
shows a boot with NM fail to start (69.40 KB, text/plain)
2008-04-29 09:14 EDT, David Timms
no flags Details
A NM trace from messages. (68.62 KB, text/plain)
2008-05-01 08:22 EDT, David Timms
no flags Details

  None (edit)
Description David Timms 2008-04-08 17:21:59 EDT
+++ This bug was initially created as a clone of Bug #385821 +++

Description of problem:
Network manager unsets the wired ethernet settings when the user logs out.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Laptop network configured to use DHCP, and start eth0 interface on boot
2. NM and NM-Dispatcher running for levels 3,4,5.
3. eth wire connected.
4. boot machine
  - ping it's server assigned dhcp address: replies
5. login screen shown
  - no replies
6. login
  - + 20-30 secs: replies.
7. logout
  - no replies !

Expected results:
wireless network should get address immediately card is detected. Network shall
not software disconnect during normal wired operation of the machine.

Additional info:
Network shall assume and keep working with most recent parameters, until a dhcp
lease change gives complete new values {to avoid situations where dns nameserver
 gets set to nothing}.

This potentially also makes sense for wireless connections - eg at home where
the moment the AP is detected, machine gets assigned address and stays connected
until out of range or machine shutdown. Why does login have any effect ?
Comment 1 Dan Williams 2008-04-10 12:09:20 EDT
Please try latest NM in koji/rawhide (svn3549).

Also, have you set up ifcfg files with system-config-network, and are those
connections set NM_CONTROLLED=yes?

NetworkManager will read your ifcfg files for wired & wireless and use those if
available, and those will persist across login/logout.
Comment 2 David Timms 2008-04-28 08:01:27 EDT
Tested with on machine upgraded from F8>F9beta>rawhide
and grabbed following from koji:

When booting, now eth0 wired:
- iptables activated during boot
- starts responding to ping as gdm {login screen} starts
- stays connected as I log in.
- stays connected as I log out.
- stays connected as I log in again.
So all looks OK.

Interestingly I have:
-rw-r--r-- 1 root root 254 2008-04-25 05:50 

cat /etc/sysconfig/network-scripts/ifcfg-eth0.bak 
# Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet

ie: no "NM_CONTROLLED=yes"

# service network status
Configured devices:
lo davidtdesktop re_melb
Currently active devices:
lo eth0

This is also the same and OK on another machine that was updated
F8>F9preview>rawhide to NM svn3566.
Comment 3 David Timms 2008-04-28 10:58:14 EDT
on 0.9.2.svn3614.fc9.i386 and with NM_CONTROLL=yes. Should the network stay
connected if you are:
- in init 5
- ctrl-alt-F1
- login as user
- su -c '\sbin\telinit 3'   {or 2} ?

It didn't. 

Added NetworkManager to levels 234. Now, I can telinit 3 from gnome and network
stays up. telinit to 2 and network stays up.

Rebooting and appending 2 or 3 on the kernel line, has trouble:
/sbin/service NetworkManager status
NetworkManager dead but pid file exists

/sbin/service NetworkManager stop
/sbin/service NetworkManager restart gets it going, and it gets an address
within a five seconds, and responds to ping.

Like a different bug for that situation, or is that expected ?
Comment 4 Dan Williams 2008-04-28 12:06:48 EDT
David; latest koji builds here:


make NM active at runlevel 2.  You may need to reset priorities though with
chkconfig.  Is there any message in /var/log/messages about NM?  Did NM crash,
perhaps because HAL wasn't up yet?
Comment 5 David Timms 2008-04-28 18:50:39 EDT
Created attachment 304052 [details]
var/log/message indicating NM trouble bzip2ed

(In reply to comment #4)
> David; latest koji builds here:
Yes that's what I was using in comment #3

> make NM active at runlevel 2.
# chkconfig --list NetworkManager
NetworkManager	0:off	1:off	2:on	3:on	4:on	5:on	6:off

> You may need to reset priorities though with chkconfig.
# chkconfig NetworkManager resetpriorities

> Is there any message in /var/log/messages about NM?  Did NM crash,
> perhaps because HAL wasn't up yet?
Yes: I have added some extra debuginfos, and am about to try again, but here is
the log up2 this point: search for ** START **
Comment 6 David Timms 2008-04-29 09:14:28 EDT
Created attachment 304114 [details]
shows a boot with NM fail to start

note: I echoed a message >> to log at the point of service NetworkManager

I see this weird console kit error during the network plug events:
Apr 29 22:51:52 davidtnotebook console-kit-daemon[2273]: WARNING: Couldn't read
/proc/3698/environ: Error reading file '/proc/3698/environ': No such process

It didn't crash with a backtrace like the previous attachment.
Comment 7 David Timms 2008-04-30 10:02:24 EDT
Based on some f-test-list discussion I tried:
# chkconfig haldaemon resetpriorities
# chkconfig NetworkManager resetpriorities

- NetworkManager doesn't start during normal boot.
- service NetworkManager restart says Failed, OK, OK
- service NetworkManager status
NetworkManager dead but pid file exists

- service haldaemon start, OK.
- service NetworkManager restart says Failed, OK, OK
Now Network manager icon appears and it does it's thing.
Comment 8 Dan Williams 2008-05-01 06:37:35 EDT
Any chance you could grab the /var/log/messages from that attempt?  If NM is
dead (but left a PID) it probably crashed, and we'd need to grab the log to try
to see where it crashed...

Also, which svn version is this?  Latest from koji (svn3623) or something before
Comment 9 David Timms 2008-05-01 08:22:07 EDT
Created attachment 304306 [details]
A NM trace from messages.

# rpm -qa kerne\* Net\* dbu\* hal\*|sort
[root@davidtnotebook log]# rpm -Va kerne\* Net\* dbu\* hal\*|sort
[root@davidtnotebook log]# sestatus
SELinux status: 		enabled
SELinuxfs mount:		/selinux
Current mode:			enforcing
Mode from config file:		enforcing
Policy version: 		22
Policy from config file:	targeted

disclaimer: I have been renaming my var/log/messages, before restarting my
notebook. But quite often the clock keeps getting screwed. I can't be 100% sure
that the versions above were active when the preceding NetMan oops occured.
Comment 10 Bug Zapper 2008-05-14 05:09:21 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 11 Dan Williams 2008-10-11 16:19:22 EDT
Should be long-fixed; if the connection is a system connection from an ifcfg file, NM will honor it before login.

Note You need to log in before you can comment on or make changes to this bug.