Disabling NetworkManager on Servers and Workstations

Why not using NetworkManager in some cases

NetworkManager is a great tool for managing connectivity on Notebooks and other mobile devices, On server or desktop machines with a complex network setup such as a combination of bonding, bridging and VLAN its probably not the best choice, at least I was not able to configure it that way. This was some time ago (approx 1y), meanwhile it may have changed.

Removing NetworkManager

Unfortunately on a desktop system its impossible to get rid of NetworkManager, there are too many really weird dependencies. On servers without a GUI it is very easy to uninstall it, IIRC no drawbacks so far.

To remove NetworkManager run

system:~# yum remove NetworkManager

Be careful, there can a a lot of dependencies getting uninstalled as well. Handle with care.

Solution w/o removing NetworkManager

Disabling the NetworkManager itself is easy,

system:~# systemctl stop NetworkManager
system:~# systemctl disable NetworkManager
system:~# systemctl mask NetworkManager

Unfortunately the NetworkManager-wait-online.service Systemd unit file can not be disabled, its enabled even when systemctl status says its disabled. At the end this means that the boot process will take 30 seconds longer than needed, that is the timeout defined for /usr/bin/nm-online.

You can check the boot process which step is to blame for the long boot time with systemd-analyze blame.

system:~# systemd-analyze blame|grep NetworkManager
          30.060s NetworkManager-wait-online.service
system:~# 

Changing the Systemd unit file

Never ever edit a systemd unit file in /usr/lib/systemd/system/ as they get overwritten with the next software update (in this case NetworkManager).

You can simply copy the unit file to the systemd local config directory /etc/systemd/system.

system:~# cp NetworkManager-wait-online.service /etc/systemd/system

You now replace the /usr/bin/nm-online with /usr/bin/true which always exits with 0.

system:~# sed -i "s|/usr/bin/nm-online -s -q --timeout=30|/usr/bin/true|g" /etc/systemd/system/NetworkManager-wait-online.service

Reload the Systemd daemon

system:~# systemctl daemon-reload 

Ensure the Symlink is correct

system:~# systemctl disable NetworkManager-wait-online.service
system:~# systemctl enable NetworkManager-wait-online.service

Further reading

Have fun 🙂

Why journalctl is cool and syslog will survive for another decade

There was a recent discussion going on if Fedora 20 should drop rsyslog and just using systemd journal. A lot of people are afraid of systemd and its journal, this a pity.

Well, there are pros and cons about this kind of logging. For System administrators daily use, journalctl is a powerful tool simplifying the hunt for log file entries.

On the other hand, there are AFAIK no monitoring tools (yet) that can work with journalctl. Those first need to be developed. A Nagios plug-in should be implemented quite quickly.

Why makes journalctl the life easier?
Instead of grepping trough thousands of lines in /var/log/messages you simply can filter the messages and work on them.

journalctl has auto completion (just hit the tab key) showing you the options to use. I.e.

fedora:~# journalctl  < TAB > 
_AUDIT_LOGINUID=             __MONOTONIC_TIMESTAMP=
_AUDIT_SESSION=              _PID=
_BOOT_ID=                    PRIORITY=
_CMDLINE=                    __REALTIME_TIMESTAMP=
CODE_FILE=                   _SELINUX_CONTEXT=
CODE_FUNC=                   _SOURCE_REALTIME_TIMESTAMP=
CODE_LINE=                   SYSLOG_FACILITY=
_COMM=                       SYSLOG_IDENTIFIER=
COREDUMP_EXE=                SYSLOG_PID=
__CURSOR=                    _SYSTEMD_CGROUP=
ERRNO=                       _SYSTEMD_OWNER_UID=
_EXE=                        _SYSTEMD_SESSION=
_GID=                        _SYSTEMD_UNIT=
_HOSTNAME=                   _TRANSPORT=
_KERNEL_DEVICE=              _UDEV_DEVLINK=
_KERNEL_SUBSYSTEM=           _UDEV_DEVNODE=
_MACHINE_ID=                 _UDEV_SYSNAME=
MESSAGE=                     _UID=
MESSAGE_ID= 
fedora:~# journalctl 

Quite some filtering options available here. Most of this options are self-explanatory.

If you just want to see the entries made by a particular command, issue journalctl _COMM= and the TAB key.

fedora:~# journalctl _COMM=
abrtd            dnsmasq          mtp-probe        sh               tgtd
anacron          gnome-keyring-d  network          smartd           udisksd
avahi-daemon     hddtemp          polkit-agent-he  smbd             umount
bash             journal2gelf     polkitd          sshd             userhelper
blueman-mechani  kdumpctl         pulseaudio       sssd_be          yum
chronyd          krb5_child       qemu-system-x86  su               
colord           libvirtd         sealert          sudo             
crond            logger           sendmail         systemd          
dbus-daemon      mcelog           setroubleshootd  systemd-journal  
fedora:~# journalctl _COMM=

If you enter journalctl _COMM=sshd you will just see the messages created by sshd.

fedora:~# journalctl _COMM=sshd 
-- Logs begin at Tue 2013-07-23 08:46:28 CEST, end at Wed 2013-07-24 11:10:01 CEST. --
Jul 23 09:48:45 fedora.example.com sshd[2172]: Server listening on 0.0.0.0 port 22.
Jul 23 09:48:45 fedora.example.com sshd[2172]: Server listening on :: port 22.
fedora:~#

Usually one is just interested in messages within a particular time range.

fedora:~# journalctl _COMM=crond --since "10:00" --until "11:00"
-- Logs begin at Tue 2013-07-23 08:46:28 CEST, end at Wed 2013-07-24 11:23:25 CEST. --
Jul 24 10:20:01 fedora.example.com CROND[28305]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jul 24 10:50:01 fedora.example.com CROND[28684]: (root) CMD (/usr/lib64/sa/sa1 1 1)
fedora:~#   

And why will rsyslog stay another decade or even longer?

There are a lot of tools and scripts which are in place since a long time, some of them even come from a time before Linux was born.

Most of those scripts must be rewritten or at least change its behaviour. I.e taking input from STDIN instead of a log file, so those tools can digest the output from journalctl|your-super-duper-scipt.pl

For log digesting tools that are needed to be compatible between different Unix and Linux Systems they probably wont be changed. In this case syslogd will survive until the last of those systems is decommissioned.

Further reading