I'm showing hundreds of frequently repeated entries in /var/log/messages that don't make sense.  More below the example.Here's an example, which is repeated ad nauseam in the log file:Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 1 of 5 (Device Prepare) scheduled...Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 1 of 5 (Device Prepare) started...Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 2 of 5 (Device Configure) scheduled...Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 1 of 5 (Device Prepare) complete.Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 2 of 5 (Device Configure) starting...Oct 15 15:14:01 mybox NetworkManager[2570]: <info> (em2): device state change: 4 -> 5 (reason 0)Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 2 of 5 (Device Configure) successful.Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 3 of 5 (IP Configure Start) scheduled.Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 2 of 5 (Device Configure) complete.Oct 15 15:14:01 mybox NetworkManager[2570]: <info> Activation (em2) Stage 3 of 5 (IP Configure Start) started...Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 4 of 5 (IP4 Configure Timeout) scheduled...Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 4 of 5 (IP4 Configure Timeout) started...Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 5 of 5 (IP Configure Commit) scheduled...Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 4 of 5 (IP4 Configure Timeout) complete.Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 5 of 5 (IP Configure Commit) started...Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 5 of 5 (IP Configure Commit) failed (no IP configuration found)Oct 15 15:14:46 mybox NetworkManager[2570]: <info> (em2): device state change: 7 -> 9 (reason 5)Oct 15 15:14:46 mybox NetworkManager[2570]: <warn> Activation (em2) failed.Oct 15 15:14:46 mybox NetworkManager[2570]: <info> Activation (em2) Stage 5 of 5 (IP Configure Commit) complete.Oct 15 15:14:46 mybox NetworkManager[2570]: <info> (em2): device state change: 9 -> 3 (reason 0)Oct 15 15:14:46 mybox NetworkManager[2570]: <info> (em2): deactivating device (reason: 0).I originally had two interfaces on this machine, but am now only using one (em1).  The second interface (em2) no longer exists in /etc/sysconfig/network-scripts/The networking service has been restarted, and the machine itself.  Still  getting references to em2.   I've looked in /etc for hidden config entries with find /etc/ -exec grep -Hn em2 {} \;But nothing comes up for em2 (aside from garbage text in sha/md5 strings)Couple questions: 1) Where else would NetworkManager be pulling config data from?  Or is NM seeing a physical card and trying to bring it up even though a network interface script doesn't exist?2) Is NetworkManager absolutely required for managing network interfaces?  This machine uses a min install of CentOS 6.  I think NM was installed early on but I later used vim to hand configure the network scripts.  The primary interface (em1) works fine. 
Why is NetworkManager attempting to control an interface script that doesn't exist?
networking;centos;networkmanager
Is NetworkManager absolutely required for managing network interfaces? No. You can disable it and set stuff up yourself if you want. I've been doing this for years on personal systems since there's barely any network managing to do anyway, and I find NM a little irritating.You do have to learn how to use stuff like ifconfig/ip, dhclient/dhcpcd, wpa_supplicant, etc.  The only issue I've ever had is automating wifi to reconnect when necessary.  That got solved with a script:#!/bin/sh. $UTIL_SRC_DIR/util-func.shcheckForSame. /etc/wifi.confexec 1> /dev/nullexec 2>> $logecho $(date) > $log# without check_interval set, we risk a 0 sleep = busy loopif [ ! $check_interval ]; then    echo No check interval set! >> $log    exit 1fistartWifi () {    dhclient -v -r    killall dhclient    iwconfig $wlan essid $essid    dhclient -v $wlan}ifconfig $eth downifconfig $wlan upstartWifiwhile [ 1 ]; do    ping -c 1 $router_ip & wait $!    if [ $? != 0 ]; then        echo -e \n$(date) attempting restart... >> $log        startWifi        sleep 1    else sleep $check_interval    fidoneThe checkForSame() thing just ensures this isn't running already.  I live out in the country and don't use wifi encryption at home, so startWifi() is pretty simple. My main point here is the logic (pinging the router and killing previous dhclients before restart), and I can report this works like a charm: it does report the occasional reconnect in the log, but I never notice any interruptions (disconnects seem to occur when the interface is idle).