On 04/06/2012 04:46 AM, Ken Teh wrote:
> Is it true that the network manager service turns off the network when
> there is no activity?
>
> I just discovered that my desktops lost connection to the authentication
> server. So, screen locks, gdm logins, remote ssh just stopped working.
> Only when I logged in as root on the console did I notice that the
> network was disabled and when I clicked on the the panel icon, it
> reconnected.
>
> Is there some special config for the network manager to stop it from
> doing this? Is there a kickstart option for this as well?
>
> I have, for the moment, disabled the network manager service and edited
> the ifcfg-ethX files so they are no longer controlled by NM. I did this
> for my headless servers, but I was surprised (annoyed is more accurate)
> that this also affects "standard" client desktops.

Your /etc/sysconfig/network-scripts/ifcfg-foo must have ONBOOT="yes", 
NM_CONTROLLED="yes" and DEFROUTE="yes" (I think this is only important 
if you are multihomed) marked for your system to initiate a connection 
without any user intervention. I believe this winds up being the case if 
you check "Available to all users" True and "Connect automatically" True 
on your primary (or only) connection.

I have many clients and servers running with various userland 
configurations, and all use NetworkManager to manage their connections. 
Kerberos, LDAP, Postgres and NFS have never had connectivity issues 
(though LDAP is a pain in other ways sometimes).

If you're losing your connections something else is likely the cause; 
most of the really bad NM problems were solved a few years ago (but the 
stigma lives on).

Here's a sample ifcfg-eth0 for IPv4 only that works fine:

DEVICE="eth0"
BOOTPROTO="none"
HWADDR="01:23:45:67:89:0A"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=192.168.12.124
PREFIX=24
GATEWAY=192.168.12.1
DNS1=192.168.12.5
DNS2=192.168.12.10
DOMAIN=shinden.tsuriai.jp
DEFROUTE="yes"
IPV4_FAILURE_FATAL="yes"
IPV6INIT="no"
NAME="System eth0"

-z