How to patch kde-plasma/plasma-firewall-5.21.2 for UFW in Gentoo Linux with OpenRC

Unfortunately plasma-firewall-5.21.2, a new Plasma frontend for firewalld and UFW, has been written only for Linux installations with systemd. However, I use OpenRC and syslog-ng in Gentoo Linux and wanted to try to get plasma-firewall to work on my laptop which uses UFW. I therefore set about patching plasma-firewall-5.21.2. I did not touch the firewalld part of plasma-firewall, as I do not use firewalld (and the plasma-firewall code for firewalld is more complicated). Below is what I did.

root # wget https://invent.kde.org/plasma/plasma-firewall/-/archive/Plasma/5.21/plasma-firewall-Plasma-5.21.tar.gz
root # tar -xzf plasma-firewall-Plasma-5.21.tar.gz
root # cp -pr plasma-firewall-Plasma-5.21 a
root # cp -pr plasma-firewall-Plasma-5.21 b
root # nano b/kcm/backends/ufw/ufwclient.cpp # Apply changes shown in Part 1 below.
root # nano b/kcm/backends/ufw/helper/helper.cpp # Apply changes shown in Part 2 below.
root # nano /usr/bin/print_ufw_messages # Create Bash script shown in Part 2 below.
root # chmod 755 /usr/bin/print_ufw_messages
root # nano b/kcm/backends/ufw/ufwlogmodel.cpp # Apply changes shown in Part 3 below.
root # diff -ruN a b > plasma-firewall-5.21.2-ufw.patch
root # mkdir -p /etc/portage/patches/kde-plasma/plasma-firewall-5.21.2
root # cp plasma-firewall-5.21.2-ufw.patch /etc/portage/patches/kde-plasma/plasma-firewall-5.21.2/
root # emerge -1v plasma-firewall
root # nano /etc/syslog-ng/syslog-ng.conf # Apply changes shown in Part 4 below.

You should now be able to use plasma-firewall for UFW in KDE Plasma’s ‘System Settings’ > ‘Firewall’ in the Network section, although I have not tried all the functions. Additionally, I believe there may be some outstanding bugs in the original 5.21.2 version of the Plasma module when using it with systemd.

Part 1

In /kcm/backends/ufw/ufwclient.cpp change:

bool UfwClient::isCurrentlyLoaded() const
{
QProcess process;
const QString name = "systemctl";
const QStringList args = {"status", "ufw"};

process.start(name, args);
process.waitForFinished();

// systemctl returns 0 for status if the app is loaded, and 3 otherwise.
qDebug() << "Ufw is loaded?" << (process.exitCode() == EXIT_SUCCESS);

return process.exitCode() == EXIT_SUCCESS;
}

to:

bool UfwClient::isCurrentlyLoaded() const
{
QProcess process;
const QString name = "rc-service";
const QStringList args = {"--exists", "ufw"};

process.start(name, args);
process.waitForFinished();

// "rc-service --exists" returns 0 if the app is loaded, and -1 otherwise.
qDebug() << "Ufw is loaded?" << (process.exitCode() == EXIT_SUCCESS);

return process.exitCode() == EXIT_SUCCESS;
}

Part 2

In /kcm/backends/ufw/helper/helper.cpp change:

QStringList getLogFromSystemd(const QString &lastLine)
{
QString program = "journalctl";
QStringList arguments {"-xb","-n", "100","-g", "UFW"};

QProcess myProcess;
myProcess.start(program, arguments);
myProcess.waitForFinished();

auto resultString = QString(myProcess.readAllStandardOutput());
auto resultList = resultString.split("\n");

// Example Line from Systemd:
// Dec 06 17:42:45 tomatoland kernel: [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=192.168.50.181 DST=224.0.0.252 LEN=56 TOS=0x00
//     PREC=0x00 TTL=255 ID=52151 PROTO=UDP SPT=5355 DPT=5355 LEN=36
// We need to remove everything up to the space after ']'.

QStringList result;
for(const QString& line : resultList) {
if (!lastLine.isEmpty() && line == lastLine) {
result.clear();
continue;
}
result.append(line);
}
return result;
}

to:

QStringList getLogFromSystemd(const QString &lastLine)
{
QString program = "print_ufw_messages";
QStringList arguments {"UFW", "100"};

QProcess myProcess;
myProcess.start(program, arguments);
myProcess.waitForFinished();

auto resultString = QString(myProcess.readAllStandardOutput());
auto resultList = resultString.split("\n");

// Example line from /var/log/messages populated by sylog-ng:
// Mar  6 00:10:19 localhost kernel: [UFW BLOCK] IN=wlan0 OUT= MAC=00:12:5b:8a:83:6d:b7:2a:da:59:d4:10:09:00 SRC=192.168.1.27
//      DST=192.168.1.139 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=41659 DF PROTO=TCP SPT=445 DPT=52140 WINDOW=260 RES=0x00 ACK URGP=0
// We need to remove everything up to the space after ']'.

QStringList result;
for(const QString& line : resultList) {
if (!lastLine.isEmpty() && line == lastLine) {
result.clear();
continue;
}
result.append(line);
}
return result;
}

where the program print_ufw_messages is a user-created Bash script /usr/bin/print_ufw_messages (-rwxr-xr-x root.root) containing:

#!/bin/bash
awk '{if (/localhost syslog-ng/ && /syslog-ng starting up/ && !/COMMAND/) {chunk=""} else {chunk=chunk $0 RS}} END {printf "%s", chunk}' /var/log/messages | grep "$1" | head -n "$2" | grep -v print_ufw_messages

Part 3

During my investigations into how to modify the plasma-firewall-5.21.2 source code, I discovered a bug in the source code. In /kcm/backends/ufw/ufwlogmodel.cpp change:

for (const QString& key : {"IN", "SRC", "DST", "PROTO", "STP", "DPT"}) {

to:

for (const QString& key : {"IN", "SRC", "DST", "PROTO", "SPT", "DPT"}) {

i.e. “STP” needs to be changed to “SPT“.

Part 4

I am not sure if this makes a difference to plasma-firewall (which was coded assuming systemd-journald is installed), but the default date format for messages in /var/log/messages printed by syslog-ng has only one digit in the day of the month when it is less than the 10th day of the month. For example:

Mar  9 03:09:39 clevow230ss syslog-ng[23735]:  syslog-ng starting up; version='3.30.1'

However, systemd-journalctl always outputs two-digit days of the month, and I think (but am not certain) the following date format might be needed in order for the existing code in /kcm/backends/ufw/ufwlogmodel.cpp to parse the syslog-ng output correctly:

Mar 09 03:09:39 clevow230ss syslog-ng[23735]:  syslog-ng starting up; version='3.30.1'

Therefore edit /etc/syslog-ng/syslog-ng.conf and add a template:

template template_date_format {
template("${MONTH_ABBREV} ${DAY} ${HOUR}:${MIN}:${SEC} ${HOST} ${MSGHDR}${MSG}\n");
template_escape(no);
};

and change the line:

destination messages { file("/var/log/messages"); };

to:

destination messages { file("/var/log/messages" template(template_date_format)); };

Then restart syslog-ng:

root # rc-service syslog-ng restart

From now on the day of the month is always two digits (01, 02,…31) in /var/log/messages.

Using NetworkManager in Gentoo Linux

My current two laptops running Gentoo Linux (both with OpenRC, elogind, eudev and wpa_supplicant) use NetworkManager rather than Netifrc. (Actually, my desktop machines also use NetworkManager even though they are always connected to the same network.) NetworkManager has worked with wired and wireless networking on these laptops without any issues for over five years now. This post summarises how it is installed and configured.

I installed the package with the following USE flags enabled:

bluetooth dhclient elogind introspection modemmanager ncurses nss policykit ppp wext wifi

and the following USE flags disabled:

audit connection-sharing dhcpcd gnutls iwd json ofono ovs resolvconf selinux systemd teamd test vala

The precise status can be seen in the output of the eix command on my main laptop that uses Gentoo Stable:

root # eix -I net-misc/networkmanager
[I] net-misc/networkmanager
     Available versions:  [M]~1.22.10-r12^t 1.26.4^t ~1.26.6^t ~1.28.0-r1^t {audit bluetooth +concheck connection-sharing debug (+)dhclient dhcpcd elogind examples (+)gnutls gtk-doc (+)introspection iwd json libpsl lto (+)modemmanager ncurses (+)nss ofono ovs (+)policykit (+)ppp resolvconf selinux syslog systemd teamd test +tools vala (+)wext +wifi ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"}
     Installed versions:  1.26.4^t(00:33:18 02/01/21)(bluetooth dhclient elogind introspection modemmanager ncurses nss policykit ppp wext wifi -audit -connection-sharing -dhcpcd -gnutls -iwd -json -ofono -ovs -resolvconf -selinux -systemd -teamd -test -vala ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux")
     Homepage:            https://wiki.gnome.org/Projects/NetworkManager
     Description:         A set of co-operative tools that make networking simple and straightforward

I use network file systems, so I also configured the netmount service to run, and specified that NetworkManager is the network manager:

root # grep -v "^#\|^$" /etc/conf.d/netmount
rc_need="NetworkManager"

The network-related services that I configured to be started at boot are as follows:

root # rc-update show -v | grep -i net
       NetworkManager |      default
                local |      default nonetwork
           net-online |
         net.enp4s0f1 |
               net.lo |
             netmount |      default

(It is correct that net-online, net.enp4s0f1 and net.lo are not in any runlevel.)

Neither dhcpd nor dhcpcd services must be started at boot, as they would interfere with NetworkManager:

root # rc-update show -v | grep -i dhcp
               dhcpcd |   
                dhcpd |

By the way, if the output of the command ‘rc-update show -v‘ incudes non-existent physical interfaces not shown in the output of the ‘ifconfig‘ or ‘ip a‘ commands, you can delete the corresponding symlinks. For example, the only physical interfaces listed by the ifconfig command on my older laptop running Gentoo Linux Testing (~amd64) are eth0 and wlan0, but the ‘rc-update show -v‘ command originally showed many other interfaces, so I deleted them as follows:

root # cd /etc/init.d/
root # rm net.aol
root # rm net.ra*
root # rm net.ath*
root # rm net.eth[1,2,3,4,5,6,7,8]
root # rm net.ppp*
root # rm net.wlan[1,2,3]

The installation on that laptop is left with the correct symlinks:

root # ls -la /etc/init.d/net.*
lrwxrwxrwx 1 root root     6 Mar 30  2010 /etc/init.d/net.eth0 -> net.lo
-rwxr-xr-x 1 root root 19861 Feb 15 01:05 /etc/init.d/net.lo
lrwxrwxrwx 1 root root     6 Mar 30  2010 /etc/init.d/net.wlan0 -> net.lo

Anyway, coming back to my main laptop, all the services running in Gentoo Linux on it are shown below, for information:

root # rc-status
Runlevel: default
 dbus                                                       [  started  ]
 NetworkManager                                             [  started  ]
 netmount                                                   [  started  ]
 syslog-ng                                                  [  started  ]
 cupsd                                                      [  started  ]
 samba                                                      [  started  ]
 cronie                                                     [  started  ]
 clamd                                                      [  started  ]
 bluetooth                                                  [  started  ]
 xdm                                                        [  started  ]
 wsdd                                                       [  started  ]
 cups-browsed                                               [  started  ]
 sshd                                                       [  started  ]
 local                                                      [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 xdm-setup                                                  [  started  ]
 avahi-daemon                                               [  started  ]
Dynamic Runlevel: manual

I specified the laptop’s hostname in /etc/hosts, /etc/conf.d/hostname, /etc/hostname and /etc/dhcp/dhclient.conf:

root # grep -v "^#\|^$" /etc/hosts
127.0.0.1       clevow230ss     localhost
::1             clevow230ss     localhost
root # cat /etc/conf.d/hostname
# Set to the hostname of this machine
hostname="clevow230ss"
root # cat /etc/hostname
clevow230ss
root # grep -v "^#\|^$" /etc/dhcp/dhclient.conf
send host-name "clevow230ss";
supersede host-name "clevow230ss";

The purpose of the ‘supersede‘ statement in dhclient.conf is explained in man dhclient.conf(5):

supersede [ option declaration ] ;

If for some option the client should always use a locally-configured value or values rather than whatever is supplied by the server, these values can be defined in the supersede statement.

In other words, I do not want the hostname to be specified by a dhcp server (as this has caused problems for me in the past when connected to some networks).

I edited the configuration file /etc/NetworkManager/NetworkManager.conf to contain the following:

[main]
plugins=keyfile
rc-manager=none
dhcp=dhclient
no-auto-default=*

[keyfile]
hostname=clevow230ss

In earlier days it was necessary to specify the hostname in /etc/NetworkManager/NetworkManager.conf but that is no longer required. According to NetworkManager.conf(5) man page: ‘This key is deprecated and has no effect since the hostname is now stored in /etc/hostname or other system configuration files according to build options.’ I just left it in the file because it does no harm.

NetworkManager’s configuration files for your wired and wireless connections are normally created and edited by using the GUI network configuration tool (a.k.a. ‘front end’) in the Desktop Environment, such as plasma-nm and nm-applet, but can also be created/edited manually. For example, the NetworkManager file for my home Wi-Fi connection contains the following:

root # cat /etc/NetworkManager/system-connections/BT-5DF82T.nmconnection
[connection]
id=BT-5DF82T
uuid=3190e9d6-961f-38ab-fb90-1d323e6f35d2
type=wifi
autoconnect=false
permissions=

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=BT-5DF82T

[wifi-security]
key-mgmt=wpa-psk
psk-flags=1

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

NetworkManager generates the UUID automatically, but it could be generated manually (I have never bothered to do that):

The UUID values in the config files must be unique. You can use uuidgen command line tool to generate such values. Alternatively, you can leave out UUID entirely. In that case NetworkManager will generate a UUID based on the file name.

iwd (iNet Wireless Daemon)

Note that NetworkManager can be used with iwd instead of wpa_supplicant, although I have never bothered to try iwd, as NetworkManager with wpa_supplicant works fine on my laptops. If you want to try iwd instead of wpa_supplicant, NetworkManager will have to be installed with the iwd and introspection USE flags enabled, and you may have to make sure iwd is running before NetworkManager — see the following for further details:

Gentoo Linux: A work-around to be able to Resume from Suspend to RAM when using the NVIDIA closed-source driver

My Clevo W230SS laptop has NVIDIA Optimus graphics hardware (NVIDIA GPU plus Intel IGP). I do not use Bumblebee, preferring to switch between the Intel video driver and the NVIDIA closed-source driver myself (see Switching between Intel and NVIDIA graphics processors on a laptop with NVIDIA Optimus hardware running Gentoo Linux). The laptop can suspend to RAM and resume perfectly when using the Intel video driver (but see Stopping my laptop spontaneously resuming immediately after Suspend to RAM, which is applicable whatever the GPU or IGP).

In order to be able to resume properly from Suspend-to-RAM when using the NVIDIA driver, the laptop needs to disable compositing before suspending, then re-enable compositing after resuming. For how I achieve that, see under Problem 2 in the third link above. If this is not done, the graphics on the Desktop are corrupted after resuming.

However, recently when using the NVIDIA driver and KDE Plasma 5 (I am currently using nvidia-drivers-387.22 and plasma-meta-5.11.5), when resuming from suspension the monitor would briefly display the LightDM wallpaper (I use different wallpapers for the display manager and the lock screen, so I know it was not the KDE lock screen) followed by a blank screen with a mouse pointer (which I could move normally). More recently, in between displaying the display manager’s wallpaper and the blank screen, the monitor would briefly display an earlier image of the Desktop just before the laptop suspended.

Now, I could simply leave the laptop configured to use the Intel driver. However, sometimes I need to use a CAD application and the performance is better when using the NVIDIA GPU.

There are umpteen posts on the Web about this problem, and the root cause seems to be the closed-source NVIDIA driver. I have seen the KDE lock screen mentioned in some posts as the culprit, so I disabled the lock screen (‘System Settings’ > ‘Desktop Behaviour’ > ‘Screen Locking’) but that did not solve the problem.

I put up with this for several weeks in the hope that the next release of the NVIDIA driver would fix the problem. If I suspended to RAM while the laptop was using the NVIDIA driver, I was able to resume and get to a working Desktop – albeit without the open windows and applications that had been running before suspending – by pressing Ctrl+Alt+F1 to get to TTY1, logging in as the root user and entering the command ‘/etc/init.d/xdm restart‘. However, the final straw was in a meeting a couple of weeks ago when I wanted to resume the laptop and show a worksheet to someone. The laptop monitor of course displayed a blank screen with a mouse pointer, and it took me a couple of minutes to restart the display manager, login to KDE Plasma 5 and open the spreadsheet again. So this week I decided to look into the problem to see if I could at least find a work-around that would enable the laptop to resume without needing to restart X Windows and login to Plasma 5 each time.

I created a Bash script in /etc/pm/sleep.d/ to unload the NVIDIA modules before suspending to RAM and to re-load them when resuming, but that did not solve the problem either.

I switched the rendering background from OpenGL 2.0 to OpenGL 3.1 (‘System Settings’ > ‘Display and Monitor’ > ‘Compositor’), but that did not work either. I switched the rendering backend to XRender, and that did enable the laptop to resume from suspend successfully with the NVIDIA driver, but I do not want to use that work-around. Firstly, with software rendering there is a performance hit, and, secondly, there was no KDE Desktop Cube when using XRender instead of OpenGL. I use the Desktop Cube when working, as I often have a lot of windows open on each virtual desktop (cube side), and I find it easier to use the cube than a flat UI.

Eventually I found that, after resuming, if I pressed Ctrl+Alt+F1 to get to a virtual console, logged into my user account, entered the command ‘DISPLAY=:0 /usr/bin/kwin_x11 --resume‘ and then pressed Ctrl+Alt+F7 to get back to TTY7, my Desktop would appear on TTY7. Even so, I noticed on TTY1 that the following error messages were displayed when I ran that command:

kwin_core: OpenGL 2 compositing setup failed
kwin_core: Failed to initialize compositing, compositing disabled

Anyway, the Plasma 5 Desktop was displayed on TTY7, and with the windows that were open when I suspended the laptop, so restarting KWin would at least be a viable work-around until NVIDIA fix their video driver.

I incoporated the command in my script /etc/pm/sleep.d/02-toggle-compositing like so:

#!/bin/sh
#
# Turn off compositing on hibernate or suspend
# Turn on compositing on thaw or resume

username=fitzcarraldo
userhome=/home/$username
export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"

case "$1" in
     suspend|hibernate)
          su $username -c "qdbus org.kde.KWin /Compositor suspend" &
     ;;
     resume|thaw)
          su $username -c "qdbus org.kde.KWin /Compositor resume" &
          su $username -c "/usr/bin/kwin_x11 --replace" &
     ;;
     *)
          exit $NA
     ;;
esac

It is an ugly hack, but at least now the laptop can resume properly from Suspend-to-RAM while the NVIDIA driver is being used.

Perhaps Linus Torvalds was correct. I will try to avoid NVIDIA hardware when I replace my current laptop.

Running a shell script at shutdown only (not at reboot) – a comparison between OpenRC and systemd

Gentoo Linux on my laptops uses OpenRC with SysVinit, whereas Lubuntu 17.10 on my family’s PC uses systemd. I have had to configure both Linux distributions to run a backup job at shutdown, so I thought it would be interesting to summarise the two approaches.

OpenRC

Create a Bash script /etc/local.d/10-run_on_shutdown.stop with the following contents:

#!/bin/bash
if [ `who -r | awk '{print $2}'` = "0" ]; then
    ########################################################################
    # Put Bash commands here to be executed on shutdown but not on reboot. #
    # For example, backup home directories to an external USB HDD.         #
    ########################################################################
fi

From now on the script will run to completion when you shutdown the machine, but not when you reboot it.

systemd

1. Create a Bash script /usr/local/sbin/run_on_shutdown.sh with the following contents:

#!/bin/bash
REBOOT=$( systemctl list-jobs | egrep -q 'reboot.target.*start' && echo "rebooting" || echo "not_rebooting" )
if [ $REBOOT = "not_rebooting" ]; then
    ########################################################################
    # Put Bash commands here to be executed on shutdown but not on reboot. #
    # For example, backup home directories to an external USB HDD.         #
    ########################################################################
fi

2. Create a unit file /etc/systemd/system/run_on_shutdown.service with the following contents:

[Unit]
Description=Run a Bash script at shutdown
DefaultDependencies=no
Before=shutdown.target halt.target
# If your script requires any mounted directories, add them below: 
RequiresMountsFor=/home

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/run_on_shutdown.sh

[Install]
WantedBy=halt.target shutdown.target

I have assumed the Bash script is to backup /home, so change the directory list in ‘RequiresMountsFor=‘ if the script necessitates that other directories are still mounted – see ‘man systemd.unit‘ for details.

3. Enable the unit file and start the service as follows:

user $ sudo systemctl enable run_on_shutdown.service
user $ sudo reboot

From now on, the script will run to completion when you shutdown the machine, but not when you reboot it.

Notes on the systemd solution:

There are plenty of posts on the Web suggesting how to run a script at shutdown in installations that use systemd, but the approaches either do not work in my case or they do not discriminate between shutting down and rebooting. For example, if you are wondering why I do not use ‘Conflicts=reboot.target‘ in the unit file, I found it does not prevent the Bash script from being launched when the system is rebooted (see the entry for ‘Conflicts=‘ in ‘man systemd.unit‘ for the functionality). If you are wondering why I do not simply place a script in /lib/systemd/system-shutdown/, it is because scripts in that directory are launched late in the shutdown process, after file systems have been mounted read-only. And if you are wondering why the Bash script tests if the system is rebooting (as distinct from shutting down) rather than the unit file being configured to do that, it is because the systemd shutdown target is active in any type of system termination, be it rebooting or halting, and it therefore does not help in discriminating between the termination types (see ‘man systemd.special‘). I tried several approaches in the unit file to see if it could be made to launch a Bash script when shutting down but not when rebooting, but the only solution that works for me in the Lubuntu 17.10 installation on my family’s PC uses the two files listed above working in conjunction with each other.

Furthermore, of all the unit files I found on the Web that actually make systemd launch a Bash script when a user initiates shutdown, only one of them prevents systemd from shutting down the machine before a time-consuming script has run to completion (for example a script to backup to an external HDD). I also tried using systemd-inhibit in this case, and it did not work. Looking at the manual page for systemd-inhibit, it could be used to execute a program (the example given is ‘systemd-inhibit wodim foobar.iso‘), however I found that systemd-inhibit did not prevent systemd from shutting down the machine before a Bash script to backup a single-seat, multi-user installation had run to completion.

Some background reading

  1. Easy Systemd Startup and Shutdown Scripts for Ubuntu 16.04 and Mint 18
  2. Stack Exchange Super User : How do I run a script before everything else on shutdown with systemd?
  3. Stack Overflow : how can a systemd controlled service distinguish between shutdown and reboot?
  4. Unix & Linux Stack Exchange : Systemd : How to execute script at shutdown only (not at reboot)

A method of ‘masking’ an OpenRC service (NetworkManager, in this case)

A Gentoo Linux user with an installation using OpenRC recently asked in the Gentoo Forums how to either a) disable NetworkManager so that it would not interfere with his netifrc configuration to give his installation a static IP address, or b) configure NetworkManager to use a static IP address (see the thread NetworkManager and static IP [SOLVED! THANKYOU]). In the end he solved the problem by uninstalling NetworkManager, the cleanest solution in his case given that his desktop machine is always in the same location and he does not need the features NetworkManager provides.

Now, although I use NetworkManager instead of netifrc, what intrigued me is that disabling the NetworkManager service using the standard command below does not stop the NetworkManager init script from running at boot-up:

root # rc-update delete NetworkManager default

Despite using the above command, following a reboot the NetworkManager service is still started and becomes active, and the NetworkManager daemon is running. Web browsers and other applications requiring network access still work. In order to stop the service running immediately so that his netifrc static IP address configuration could work, the aforementioned Gentoo user had to stop the NetworkManager service as follows:

root # /etc/init.d/NetworkManager stop

(The command ‘rc-service NetworkManager stop‘ does the same thing.)

The behaviour is the same on my laptop running Gentoo with OpenRC 0.22.4 and NetworkManager installed by networkmanager-1.4.0-r1 ebuild (with the upstream patch and necessary edit to the init script mentioned in Gentoo Bug Report No. 595806 – net-misc/networkmanager-1.4.0-r1[consolekit]: doesn’t automatically activate connections marked with "Automatically connect to this network when it’s available").

So two questions arose: What launches the NetworkManager init script when it has not been added to a runlevel? What needs to be done to stop this from happening? My curiosity was piqued.

As it happens, a somewhat similar situation exists when using systemd rather than OpenRC, as explained in Arch Linux Forums thread [SOLVED] NetworkManager auto restart even though I stop it. and Red Hat Bugzilla Report No. 815243 – Even though NetworkManager was manually stopped, it gets restarted automatically via D-Bus, although those were primarily concerned with how to prevent NetworkManager being restarted during the same session, i.e. without having rebooted.

The following systemd commands are needed to stop immediately the NetworkManager service and keep it from being restarted subsequently during the current session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

Unfortunately there is no equivalent mask command for an OpenRC service. The equivalent OpenRC commands for the second and third commands above are:

root # rc-service NetworkManager stop
root # rc-update delete NetworkManager default

However, as I pointed out earlier, for some reason the latter command does not stop OpenRC running the NetworkManager init script at boot.

I wondered how I could ‘mask’ the NetworkManager service in OpenRC. I asked myself what the systemd mask command actually does. Well, it simply creates a symlink from /etc/systemd/system/NetworkManager.service to /dev/null so that there is no longer a real unit file for systemd to use, and therefore systemd can no longer launch the service. So why not do something similar in OpenRC. I hit upon the idea of telling the NetworkManager init script it needs a non-existent service in order to start, thus preventing OpenRC from starting the NetworkManager service:

root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager # (Or just edit the file manually.)

That is all there is to it. When booting, OpenRC now displays the messages shown below:

* ERROR: NetworkManager needs service(s) non-existent_service
* ERROR: cannot start netmount as NetworkManager would not start
* ERROR: cannot start samba as NetworkManager would not start

As shown below, now the service is not started, so the NetworkManager daemon is never launched:

root # rc-status
Runlevel: default
 dbus                                                  [  started  ]
 syslog-ng                                             [  started  ]
 consolekit                                            [  started  ]
 netmount                                              [  stopped  ]
 cupsd                                                 [  started  ]
 samba                                                 [  stopped  ]
 cronie                                                [  started  ]
 clamd                                                 [  started  ]
 bluetooth                                             [  started  ]
 xdm                                                   [  started  ]
 cups-browsed                                          [  started  ]
 sshd                                                  [  started  ]
 local                                                 [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 modules-load                                          [  started  ]
 xdm-setup                                             [  started  ]
 avahi-daemon                                          [  started  ]
Dynamic Runlevel: manual
root # ps -ef | grep -v grep | grep -i network
root #

As expected, given that the netmount service and samba service depend on the NetworkManager service starting, neither of those services were able to start either.

Furthermore, because I masked the service, if I attempt to start it manually:

root # rc-service NetworkManager restart
 * ERROR: NetworkManager needs service(s) non-existent_service

To unmask the service in OpenRC, all that is needed is:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager # (Or just edit the file manually.)

Note that, instead of “non-existent_service” I could have written “fubar”, “null” or any other string that is not the name of an actual service. But “non-existent_service” is more meaningful and less likely to confuse me when viewing system messages and contents of the service configuration file.

In summary…

Why does OpenRC run the NetworkManager service init script when it is not in any runlevel?

I have no idea!

I wondered if the D-Bus service does it. The Arch Wiki article on NetworkManager claims this is the case (see the section titled Disable NetworkManager). However, my attempts at preventing D-Bus doing anything to NetworkManager did not stop the NetworkManager init script from being run at boot. I deleted /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf and /etc/dbus-1/system.d/nm-dispatcher.conf but that did not help. Neither did creating an appropriate /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf or /etc/dbus-1/system-local.conf. There is no /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service file in my Gentoo installation using OpenRC, but creating one did not help either. So, if you know what runs the OpenRC NetworkManager init script when it is not in any runlevel, please post a comment.

Anyway, I now know how to prevent it happening, so I have satisfied my curiosity. Below I list the commands I actually used in a Gentoo Linux installation (amd64, OpenRC) and a Sabayon Linux installation (~amd64, systemd) to check the functionality.

OpenRC

The following two (optionally three) commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # rc-service NetworkManager stop
root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager
root # rc-update del NetworkManager default # (Optional.)

The following two (optionally three) commands are needed to unmask the NetworkManager service and start it immediately, and make it start automatically after rebooting:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager
root # rc-service NetworkManager restart
root # rc-update add NetworkManager default # Only needed if I earlier deleted the service from the default runlevel.

systemd

The following three commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

The following three systemd commands are needed to unmask the NetworkManager service and start it immediately, and also make it start automatically after rebooting:

root # systemctl unmask NetworkManager
root # systemctl enable NetworkManager
root # systemctl start NetworkManager

Getting KDE Plasma 5 to work with the NVIDIA closed-source driver in Gentoo Linux

Up until a few days ago I had avoided migrating from KDE 4 to KDE Plasma 5, Frameworks 5 and Applications 5 — I’ll refer to the latter three package categories collectively as ‘KDE:5’ — on my main laptop, a Clevo W230SS with NVIDIA Optimus hardware and Gentoo Linux Stable Branch installed. My reluctance to migrate to KDE:5 was because of various problems I experience in KDE:5 on my Compal NBLB2 laptop, which has Gentoo Testing Branch installed (currently Plasma 5.7.1, which you would expect to be less buggy than Plasma 5.5.5 in the Gentoo Stable Branch).

Recently the maintainers of Gentoo’s KDE ebuilds removed some of the KDE 4 ebuilds and made some of the other ebuilds dependent on KDE:5. It became more complicated and convoluted to keep KDE 4 going, so I reluctantly threw in the towel and migrated to KDE:5 on my main laptop. I wish I could have kept KDE 4 on that machine, as KDE 4 worked extremely well (and looked great too).

My first problem after migrating was the infamous black screen in X Windows at start-up. Trying the various suggestions in the Gentoo Wiki did not help and, for the first time since I’ve owned the Clevo laptop, I was glad it has NVIDIA Optimus hardware as I was able to change from using nvidia-drivers to using xf86-video-intel, which got me to a usable Desktop after I switched display managers from SDDM (see the system log file error messages below) to LightDM.

Jul 17 04:32:37 clevow230ss sddm-helper[3245]: PAM unable to dlopen(/lib64/security/pam_systemd.so): /lib64/security/pam_systemd.so: cannot open shared object file: No such file or directory
Jul 17 04:32:37 clevow230ss sddm-helper[3245]: PAM adding faulty module: /lib64/security/pam_systemd.so

Although I had merged x11-misc/sddm with USE="-systemd" because my installation uses OpenRC, the above error messages made me suspect that something is wrong with the sddm-0.13.0-r3 ebuild, which is why I switched to LightDM.

However, using solely the Intel driver is not a long-term solution for me because DraftSight CAD software is slower with the Intel driver, so I was keen to get Plasma 5 working with the closed-source NVIDIA driver (I do not want to use Bumblebee).

I managed to get LightDM and Plasma 5 working with nvidia-drivers by doing the following:

  1. Merge x11-misc/lightdm.
  2. Re-merge kde-plasma/plasma-meta with USE="-sddm".
  3. Remove the x11-misc/sddm package and kde-plasma/sddm-kcm package by using the command ‘emerge --ask --depclean‘.
  4. Edit the file /etc/lightdm/lightdm.conf to add the line ‘greeter-session=lightdm-kde-greeter‘ as specified in Gentoo Wiki article LightDM.
  5. Edit the file /etc/lightdm/lightdm.conf to add the line ‘display-setup-script=/etc/X11/Sessions/plasma‘ (any file name would do).
  6. Create the above-mentioned Bash script /etc/X11/Sessions/plasma containing the following:
#!/bin/bash
GPU=`eselect opengl list | grep \* | awk '{ print $2 }'`
if [ "$GPU" = "nvidia" ]; then
    xrandr --setprovideroutputsource modesetting NVIDIA-0
    xrandr --auto
fi

I can now switch between the NVIDIA closed-source driver and the Intel open-source driver using the method described in an earlier post: Switching between Intel and NVIDIA graphics processors on a laptop with NVIDIA Optimus hardware running Gentoo Linux.

NetworkManager: Failed to activate – The name org.freedesktop.NetworkManager was not provided by any .service files

Because I need to connect quickly and easily to numerous wired and wireless networks (DHCP or static IP addressing), I use NetworkManager in my Gentoo Linux amd64 installation running OpenRC and KDE 4. My Clevo W230SS laptop has an Intel Dual Band Wireless-AC 7260 Plus Bluetooth adapter card, and my installation uses the iwlwifi module:

# lspci -knn | grep Net -A2
03:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev bb)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
        Kernel driver in use: iwlwifi
# lsmod | grep iwl
iwlmvm                143919  0
iwlwifi                75747  1 iwlmvm

As I am using NetworkManager instead of netifrc, in accordance with the instructions in the Gentoo Wiki article on NetworkManager I do not have any net.* services enabled (not even net.lo):

# rc-update show -v
       NetworkManager |      default                 
                acpid |                              
            alsasound |                              
         avahi-daemon |                              
       avahi-dnsconfd |                              
               binfmt | boot                         
            bluetooth |      default                 
             bootmisc | boot                         
         busybox-ntpd |                              
     busybox-watchdog |                              
                clamd |                              
          consolefont |                              
           consolekit |      default                 
               cronie |      default                 
         cups-browsed |      default                 
                cupsd |      default                 
                 dbus |      default                 
                devfs |                       sysinit
               dhcpcd |                              
                dhcpd |                              
             dhcrelay |                              
            dhcrelay6 |                              
                dmesg |                       sysinit
              dropbox |                              
           fancontrol |                              
                 fsck | boot                         
                 fuse |                              
           git-daemon |                              
                  gpm |                              
              hddtemp |                              
             hostname | boot                         
              hwclock | boot                         
            ip6tables |                              
             iptables |                              
              keymaps | boot                         
            killprocs |              shutdown        
    kmod-static-nodes |                       sysinit
           lm_sensors |                              
                local |      default                 
           localmount | boot                         
             loopback | boot                         
      mit-krb5kadmind |                              
          mit-krb5kdc |                              
       mit-krb5kpropd |                              
              modules | boot                         
             mount-ro |              shutdown        
                 mtab | boot                         
                mysql |                              
                  nas |                              
         net.enp4s0f1 |                              
               net.lo |                              
             netmount |      default                 
           ntp-client |                              
                 ntpd |                              
           nullmailer |                              
              numlock |                              
  nvidia-persistenced |                              
           nvidia-smi |                              
              osclock |                              
              pciparm |                              
               procfs | boot                         
              pwcheck |                              
            pydoc-2.7 |                              
            pydoc-3.4 |                              
               rfcomm |                              
                 root | boot                         
               rsyncd |                              
            s6-svscan |                              
                samba |      default                 
                saned |                              
            saslauthd |                              
            savecache |              shutdown        
                 sntp |                              
                 sshd |      default                 
             svnserve |                              
                 swap | boot                         
            swapfiles | boot                         
              swclock |                              
               sysctl | boot                         
                sysfs |                       sysinit
            syslog-ng |      default                 
        teamviewerd10 |                              
         termencoding | boot                         
             timidity |                              
         tmpfiles.dev |                       sysinit
       tmpfiles.setup | boot                         
               twistd |                              
                 udev |                       sysinit
                  ufw | boot                         
              urandom | boot                         
       wpa_supplicant |                              
                  xdm |      default                 
            xdm-setup |

I have left the netmount service enabled in case I want to use network-attached file shares at home or in one of the various office locations where I work.

Networking works fine on my laptop with the many wired and wireless networks I have used except for one particular public wireless network (it is in an airport, has multiple Access Points, and its Access Points only support 802.11a/b/g, which may or may not be relevant) for which the following message would usually appear in a pop-up window when I tried to connect to the network from the KDE network management GUI after start-up:

Failed to activate
The name org.freedesktop.NetworkManager was not provided by any .service files

Error message displayed by KDE when trying to connect to one specific network

Error message displayed by KDE when trying to connect to one specific network


This occurred with both networkmanager-1.0.2-r1 and networkmanager-1.0.6, the two Stable Branch releases of NetworkManager currently available in Gentoo Linux.

The wireless network is not the only network at that particular location, and the ‘Failed to activate’ message occurred whichever network (wireless or wired) I tried to access at that location. When this problem occurred, it transpired that the NetworkManager service was not running (it had crashed):

$ nmcli d
Error: NetworkManager is not running.
$ rc-status
Runlevel: default
 dbus                   [  started  ]
 NetworkManager         [  crashed  ]
 netmount               [  started  ]
 syslog-ng              [  started  ]
 cupsd                  [  started  ]
 samba                  [  crashed  ]
 consolekit             [  started  ]
 cronie                 [  started  ]
 bluetooth              [  started  ]
 xdm                    [  started  ]
 cups-browsed           [  started  ]
 sshd                   [  started  ]
 local                  [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 xdm-setup              [  started  ]
 avahi-daemon           [  started  ]
Dynamic Runlevel: manual

(I am not bothered that Samba crashes in that particular location. It crashes even if a connection is established, because the public wireless network does not provide network file systems. Samba works fine when I connect the laptop to an office network or to my home network.)

Even if the ‘Failed to activate’ message occurred, sometimes (but not always) the laptop could still connect to networks after I restarted the NetworkManager service (albeit sometimes it was necessary to restart it more than once):

# /etc/init.d/NetworkManager restart

When it is possible to connect to networks, the NetworkManager service is of course running:

$ nmcli d
DEVICE    TYPE      STATE        CONNECTION           
sit0      sit       connected    sit0                 
wlp3s0    wifi      connected    Free_Airport_Internet
enp4s0f1  ethernet  unavailable  --                   
lo        loopback  unmanaged    --        
$ rc-status
Runlevel: default
 dbus                   [  started  ]
 NetworkManager         [  started  ]
 netmount               [  started  ]
 syslog-ng              [  started  ]
 cupsd                  [  started  ]
 samba                  [  crashed  ]
 consolekit             [  started  ]
 cronie                 [  started  ]
 bluetooth              [  started  ]
 xdm                    [  started  ]
 cups-browsed           [  started  ]
 sshd                   [  started  ]
 local                  [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 xdm-setup              [  started  ]
 avahi-daemon           [  started  ]
Dynamic Runlevel: manual

I searched the Web for the error message and, based on a recommendation on the Web page ‘nm-applet gives errors‘ claiming the problem is due to the iwlwifi driver when used with an Intel 7260 controller, I created a file /etc/modprobe.d/iwlwifi.conf containing the following line, and rebooted:

options iwlwifi power_save=0

However, the error message still occurred. So I changed the iwlwifi module options line to the following, as also recommended on that page, and rebooted:

options iwlwifi 11n_disable=1 power_save=0

However, the error message still occurred.

The default value for OpenRC’s rc_depend_strict variable is YES if rc_depend_strict is not declared in the file /etc/rc.conf, but I do not think that is the cause of the problem:

# Do we allow any started service in the runlevel to satisfy the dependency
# or do we want all of them regardless of state? For example, if net.eth0
# and net.eth1 are in the default runlevel then with rc_depend_strict="NO"
# both will be started, but services that depend on 'net' will work if either
# one comes up. With rc_depend_strict="YES" we would require them both to
# come up.
#rc_depend_strict="YES"

As already mentioned, sometimes just restarting the NetworkManager service once or more did enable the laptop to connect to the network. This made me wonder whether the problem had something to do either with the timing of the launch of the NetworkManager service or with the timing of the service establishing a connection. As netmount is the only other network-related service enabled at start-up, I checked the netmount service’s configuration file /etc/conf.d/netmount to see what it contained (it’s the same in both the latest stable openrc-0.17 and the latest testing openrc-0.18.2):

# You will need to set the dependencies in the netmount script to match
# the network configuration tools you are using. This should be done in
# this file by following the examples below, and not by changing the
# service script itself.
#
# Each of these examples is meant to be used separately. So, for
# example, do not set rc_need to something like "net.eth0 dhcpcd".
#
# If you are using newnet and configuring your interfaces with static
# addresses with the network script, you  should use this setting.
#
#rc_need="network"
#
# If you are using oldnet, you must list the specific net.* services you
# need.
#
# This example assumes all of your netmounts can be reached on
# eth0.
#
#rc_need="net.eth0"
#
# This example assumes some of your netmounts are on eth1 and some
# are on eth2.
#
#rc_need="net.eth1 net.eth2"
#
# If you are using a dynamic network management tool like
# networkmanager, dhcpcd in standalone mode, wicd, badvpn-ncd, etc, to
# manage the network interfaces with the routes to your netmounts, you
# should list that tool.
#
#rc_need="networkmanager"
#rc_need="dhcpcd"
#rc_need="wicd"
#
# The default setting is designed to be backward compatible with our
# current setup, but you are highly discouraged from using this. In
# other words, please change it to be more suited to your system.
#
rc_need="net"

As I am using NetworkManager rather than netifrc, I followed the instructions in the file’s comments and changed the file’s contents from:

rc_need="net"

to:

rc_need="networkmanager"

After making the above change, the console messages at boot-up included a new message:

* ERROR: netmount needs service(s) networkmanager

That message made sense: rc_need had been set to "networkmanager" and, obviously, netmount can only do its job if NetworkManager is running (AND a network connection has been established). However, notice that the name of the NetworkManager service initscript is /etc/init.d/NetworkManager, not /etc/init.d/networkmanager. In other words, the instructions in /etc/conf.d/netmount are wrong: the name of the service is actually ‘NetworkManager‘, not ‘networkmanager‘. So I changed /etc/conf.d/netmount to contain rc_need="NetworkManager" instead of rc_need="networkmanager" and, unsurprisingly, the above-mentioned error message no longer occurs. I have filed Gentoo Bugzilla Bug Report No. 564846 requesting that the comment in the configuration file be changed.

Nevertheless, the ‘Failed to activate’ message still occurred when I tried to connect to any network at that location by using the DE’s network management GUI, and therefore I still needed to restart the NetworkManager service manually in order to be able to connect to any network there. Although I am not yet sure of the root cause and solution, I have found a work-around which avoids me having to manually restart the NetworkManager service, as explained below.

Although OpenRC correctly launches the NetworkManager service, that service remains inactive until it actually establishes a network connection. This is not a bug, it is the way OpenRC and NetworkManager work (see the explanation in the Gentoo Forums thread NetworkManager has started, but is inactive). This is why the following console message appears during boot-up:

* WARNING: NetworkManager has already started, but is inactive

If you did not configure NetworkManager to connect automatically to a network, after logging-in to the DE you will need to use the DE’s network management GUI (plasma-nm in the case if KDE, nm-applet in the case of e.g. Xfce) to tell NetworkManager to connect to the desired network. However, I found that waiting that long before trying to connect is too late to avoid the ‘Failed to activate’ problem, i.e. NetworkManager crashes after a while. I do not know why this happens, but it usually happens only when I am at the location covered by one specific wireless network (which is why I wonder if the problem is a result of that network only supporting 802.11a/b/g). By configuring NetworkManager to connect automatically to the wireless network which seemed to trigger the problem, the NetworkManager service tries to connect earlier. It is possible to configure NetworkManager to do this either by using the DE network GUI and ticking ‘Automatically connect to this network when it is available’ for the relevant network connection, or by directly editing the relevant connection’s file in the directory /etc/NetworkManager/system-connections/.

Of the various wired and wireless connections I had configured on the laptop, I had named the problematic wireless network’s connection ‘Free_Airport_Internet’. So I edited the file /etc/NetworkManager/system-connections/Free_Airport_Internet and deleted the line ‘autoconnect=false‘ in the [connections] section of the file (the default value of the autoconnect variable is TRUE – see man nm-settings). I could instead have done this by using the DE’s network manager GUI and ticking ‘Automatically connect to this network when it is available’ for that network connection. Now, when the laptop boots, NetworkManager tries to connect to that network and the ‘Failed to activate’ problem is avoided. This works with or without the iwlwifi driver options I mentioned above, so, despite the claim on the Web page I referenced above, the root cause of the problem does not appear to be the iwlwifi driver. What I don’t understand is why the problem only seems to occur with one particular network (a public wireless network which happens to only support 802.11a/b/g), i.e. even if none of the NetworkManager connection files in my installation have been configured to try to establish a connection automatically, with all the other wireless networks I have used in other locations (I believe those all support at least 802.11a/b/g/n) I have been able to establish a connection manually by using the DE’s network management GUI.

The bottom line

If your installation uses NetworkManager and you experience the ‘Failed to activate’ message when trying to connect to networks from the DE’s network management GUI, check if the NetworkManager service is running. You can check by using the command ‘nmcli d‘ in a console. If it is not running, try to restart the NetworkManager service from the command line. If the connection is not already configured to start automatically, configure it to start automatically in order to try to make NetworkManager become active at an early stage.

POSTSCRIPT (November 6, 2015)

The two links below are to old bug reports regarding earlier versions of NetworkManager having trouble using wireless networks with multiple Access Points. I wonder if the problem I saw with NetworkManager crashing when not configured to connect automatically to the specific network I mentioned above is somehow related to those problems:

background scanning causes drivers to disassociate – WiFi roaming causes NetworkManager to lose routing

network-manager roams to (none) ((none)) – background scanning

Roaming to BSSID “(none)” certainly happens with this particular network too, as shown by the messages in the laptop’s system log from yesterday when I was using the laptop with that network (the laptop was stationary the whole time):

# cat /var/log/messages | grep "Nov  5 11" | grep NetworkManager | grep \(none\)
Nov  5 11:01:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 04:C5:A4:C3:F9:EE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:01:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:13:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:13:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to 04:C5:A4:C3:F9:EE (Free_Airport_Internet)
Nov  5 11:15:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 04:C5:A4:C3:F9:EE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:15:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:19:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:19:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:49:50 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:49:50 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to 68:BC:0C:A1:3C:DE (Free_Airport_Internet)
Nov  5 11:51:51 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 68:BC:0C:A1:3C:DE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:51:51 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)

Today I’m using a hotel network in my hotel room, and that does not roam to BSSID “(none)”, but I don’t know if my room is within range of more than one Access Point:

# cat /var/log/messages | grep "Nov  6" | grep NetworkManager | grep \(none\)
#

Anyway, with the work-around described in this post I have not had any further trouble accessing the particular network, but it would be interesting to know the root cause.

Gentoo Linux: Run a script at shutdown, but not when rebooting

In Gentoo Linux it is straightforward to run scripts automatically when the OS starts (boots) and stops (either shutting down or rebooting). You simply need to place an executable script file in the directory /etc/local.d/ with the suffix ‘.start‘ or ‘.stop‘, depending on whether you want the script to run at the beginning or end of your Linux session. The file /etc/local.d/README (complete with ‘sequentially’ misspelt) explains it better:

This directory should contain programs or scripts which are to be run
when the local service is started or stopped.

If a file in this directory is executable and it has a .start extension,
it will be run when the local service is started. If a file is
executable and it has a .stop extension, it will be run when the local
service is stopped.

All files are processed in lexical order.

Keep in mind that files in this directory are processed sequencially,
and the local service is not considered started or stopped until
everything is processed, so if you have a process which takes a long
time to run, it can delay your boot or shutdown processing.

Scripts with a ‘.stop‘ suffix are launched both when you shutdown your Linux installation and when you reboot it. However, sometimes you may not want to run a script when you reboot your installation. A typical example would be a script to backup your hard drive; you would probably only want it to run when you have finished for the day and you are shutting down and powering off your machine. So, how do you achieve that? I initially thought I would be able to use the ‘runlevel‘ command or the RUNLEVEL environment variable in a script (see man runlevel regarding both). But I could not get my script /etc/local.d/10-run_on_shutdown.stop to work using either. However, the command ‘who -r‘ (‘who --runlevel‘) does work for me in Gentoo Linux with OpenRC:

$ cat /etc/local.d/10-run_on_shutdown.stop
#!/bin/bash
if [ `who -r | awk '{print $2}'` = "0" ]; then
  echo "shutting down" >> /home/fitzcarraldo/test.txt
  date >> /home/fitzcarraldo/test.txt
elif [ `who -r | awk '{print $2}'` = "6" ]; then
  echo "rebooting" >> /home/fitzcarraldo/test.txt
  date >> /home/fitzcarraldo/test.txt
else
  echo "neither rebooting nor shutting down" >> /home/fitzcarraldo/test.txt
  date >> /home/fitzcarraldo/test.txt
fi
$

After rebooting, then shutting down and booting, then rebooting again, the contents of the file test.txt show that the above-mentioned simple script works as intended:

$ cat test.txt
rebooting
Sun  6 Sep 12:42:11 BST 2015
shutting down
Sun  6 Sep 12:46:04 BST 2015
rebooting
Sun  6 Sep 12:49:31 BST 2015
$

So the following script /etc/local.d/10-run_on_shutdown.stop will do the desired job:

$ cat /etc/local.d/10-run_on_shutdown.stop
#!/bin/bash
if [ `who -r | awk '{print $2}'` = "0" ]; then
  ######################################################################
  # Put Bash commands here to be executed on shutdown but not on reboot.
  ######################################################################
fi
$

Don’t forget to make the script executable:

# chmod +x /etc/local.d/10-run_on_shutdown.stop

NetworkManager creating a new connection ‘eth0’ that does not work, Part 4

Further to my previous post, this is to report the result of another experiment. By doing all the following I can stop NetworkManager creating an invalid second eth0 connection:

  • Enable IPv6 system-wide in /etc/modprobe.d/aliases.conf by commenting-out ‘alias net-pf-10 off‘.
  • Disable use of IPv6 by the Avahi daemon in /etc/avahi/avahi-daemon.conf (see the four additional lines given in my previous post).
  • Use plasma-nm to edit the connection profile for ‘eth0’ that I had already created. Click on the IPv6 tab and ensure ‘Method: Ignored‘ is selected. Click on the IPv4 tab and ensure ‘Method: Automatic‘ is selected and ‘IPv4 is required for this connection‘ is ticked. Ticking ‘IPv4 is required for this connection‘ adds the line ‘may-fail=false‘ in the [ipv4] section in the file /etc/NetworkManager/system-connections/eth0 (the default value for may-fail is ‘true‘ if the box has not been ticked and may-fail has not been assigned in the file).

The various experiments I have conducted are summarised in the following table:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true true false false false
Invalid second eth0 created usually no usually no yes yes

As disabling IPv6 system-wide makes it impossible for NetworkManager to use IPv6, the above table can actually be written as follows:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes||no no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true||false true false false false
Invalid second eth0 created usually no usually no yes yes

I still think there is a bug in NetworkManager. I would not have expected NetworkManager to create a second eth0 connection and make it an IPv6 Link-Local connection when all the following are true:

  • /etc/NetworkManager.conf has ‘no-auto-default=eth0‘ in the [main] section.
  • IPv4 is required for this connection‘ is not ticked in plasma-nm (i.e. the [ipv4] section in /etc/NetworkManager/system-connections/eth0 contains either the line ‘may-fail=true‘ or the line ‘may-fail=‘).
  • Method: Automatic‘ is selected for IPv4 (‘method=auto‘ under [ipv4] in /etc/NetworkManager/system-connections/eth0).
  • Method: Ignored‘ is selected for IPv6 (‘method=ignore‘ under [ipv6] in /etc/NetworkManager/system-connections/eth0) and the other fields on the IPv6 tab have been rendered unselectable as a result.

Anyway, I will keep IPv6 disabled in /etc/avahi/avahi-daemon.conf and IPv6 enabled system-wide. This seems to be the first thing to try if you’re experiencing the creation of an invalid additional eth0 connection with an IPv6 Link-Local address and you’re sure that none of the net.* services are running.

NetworkManager creating a new connection ‘eth0′ that does not work, Part 3

I’m even more convinced the problem discussed in my previous post is due to a bug in NetworkManager. I believe the issue with the Avahi daemon generating an IPv6 Link-Local address is a consequence of NetworkManager not always activating an interface and therefore not obtaining an IPv4 address, i.e. the IPv6 Link-Local address produced by the Avahi daemon is a side effect, not the root cause.

After my previous post I discovered that adding ‘use-ipv6=no‘ in /etc/avahi/avahi-daemon.conf (my Experiment 2) had not prevented avahi-daemon using IPv6. However, adding the following lines in /etc/avahi/avahi-daemon.conf defintely does prevent avahi-daemon from using IPv6 in my installation:

use-ipv4=yes
use-ipv6=no
publish-a-on-ipv6=no
publish-aaaa-on-ipv4=no

You can see in the message log below that the Avahi daemon is no longer generating an IPv6 Link-Local address. However, even with IPv6 disabled in avahi-daemon, an invalid second eth0 connection with an IPv6 Link-Local address still occurs in my installation. This indicates the problem is not caused by the Avahi daemon.

Mar 18 22:17:31 localhost syslog-ng[8316]: syslog-ng starting up; version='3.6.2'
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  NetworkManager (version 1.0.0) is starting...
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  Read config: /etc/NetworkManager/NetworkManager.conf
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  WEXT support is enabled
Mar 18 22:17:34 localhost kernel: fglrx_pci 0000:01:00.0: irq 34 for MSI/MSI-X
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8351
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8352
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8353
Mar 18 22:17:34 localhost kernel: <6>[fglrx] IRQ 34 Enabled
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e2000, size:4000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e6000, size:51a000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:3fff3000, size:d000 
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/Cisco00497
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/eth0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/DIRECT-HeC460 Series
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  monitoring kernel firmware directory '/lib/firmware'.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi hardware radio set enabled
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN hardware radio set enabled
Mar 18 22:17:33 localhost /etc/init.d/NetworkManager[8326]: WARNING: NetworkManager has started, but is inactive
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wwan.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi disabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiMAX enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Networking is enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): new Generic device (driver: 'unknown' ifindex: 1)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): exported as /org/freedesktop/NetworkManager/Devices/0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): new Ethernet device (driver: 'atl1c' ifindex: 2)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  startup complete
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: starting connection 'eth0'
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): using nl80211 for WiFi device control
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 3)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): exported as /org/freedesktop/NetworkManager/Devices/2
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): preparing device
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) starting...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) successful.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 22:17:33 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ModemManager1' (using servicehelper)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  NetworkManager state is now CONNECTED_LOCAL
Mar 18 22:17:33 localhost acpid[8386]: starting up with netlink and the input layer
Mar 18 22:17:33 localhost acpid[8386]: 6 rules loaded
Mar 18 22:17:33 localhost acpid[8386]: waiting for events: event logging is off
Mar 18 22:17:34 localhost ModemManager[8385]: <info>  ModemManager (version 1.4.2) starting in system bus...
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  (eth0): Activation: successful, device activated.
Mar 18 22:17:34 localhost dbus[7763]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 22:17:34 localhost nm-dispatcher[8435]: Dispatching action 'up' for eth0
Mar 18 22:17:34 localhost rpc.statd[8451]: Version 1.3.2 starting
Mar 18 22:17:34 localhost rpc.statd[8451]: Flags: TI-RPC 
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8457]: status: inactive
Mar 18 22:17:34 localhost rpc.statd[8451]: Running as root.  chown /var/lib/nfs to choose different user
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8469]: status: inactive
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ModemManager1'
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager disappeared from bus
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager available in the bus
Mar 18 22:17:35 localhost sm-notify[8556]: Version 1.3.2 starting
Mar 18 22:17:35 localhost avahi-daemon[8585]: Found user 'avahi' (UID 108) and group 'avahi' (GID 444).
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped root privileges.
Mar 18 22:17:35 localhost avahi-daemon[8585]: avahi-daemon 0.6.31 starting up.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully called chroot().
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped remaining capabilities.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/sftp-ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Network interface enumeration completed.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Registering HINFO record with values 'X86_64'/'LINUX'.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Server startup complete. Host name is meshedgedx.local. Local service cookie is 3778762828.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/ssh.service) successfully established.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/sftp-ssh.service) successfully established.
Mar 18 22:17:35 localhost ntpd[8645]: ntpd 4.2.8@1.3265-o Wed  4 Mar 02:23:30 UTC 2015 (1): Starting
Mar 18 22:17:35 localhost ntpd[8645]: Command line: ntpd -g -q
Mar 18 22:17:35 localhost ntpd[8645]: proto: precision = 0.061 usec (-24)
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 0 v6wildcard [::]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 2 lo 127.0.0.1:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 3 lo [::1]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 4 eth0 [fe80::725a:b6ff:fe3e:c18a%2]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listening on routing socket on fd #21 for interface updates
Mar 18 22:17:36 localhost kernel: fbcondecor: console 1 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 1
Mar 18 22:17:37 localhost kernel: fbcondecor: console 2 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 2
Mar 18 22:17:37 localhost kernel: fbcondecor: console 3 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 3
Mar 18 22:17:37 localhost kernel: fbcondecor: console 4 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 4
Mar 18 22:17:37 localhost kernel: fbcondecor: console 5 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 5
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth daemon 5.28
Mar 18 22:17:36 localhost bluetoothd[8787]: Starting SDP server
Mar 18 22:17:37 localhost kernel: Bluetooth: Core ver 2.19
Mar 18 22:17:37 localhost kernel: NET: Registered protocol family 31
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI device and connection manager initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: L2CAP socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: SCO socket layer initialized
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP filters: protocol multicast
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP socket layer initialized
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth management interface 1.7 initialized
Mar 18 22:17:36 localhost NetworkManager[8346]: <info>  use BlueZ version 5
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by any plugin
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
Mar 18 22:17:39 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper)
Mar 18 22:17:39 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ColorManager'
Mar 18 22:17:41 localhost kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost laptop-mode[8947]: Laptop mode 
Mar 18 22:17:43 localhost laptop-mode[8948]: enabled, not active
Mar 18 22:17:58 localhost kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Mar 18 22:17:58 localhost rpc.mountd[9741]: Version 1.3.2 starting
Mar 18 22:17:59 localhost kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Mar 18 22:17:59 localhost kernel: NFSD: starting 90-second grace period (net ffffffff81c3d580)
Mar 18 22:17:58 localhost sm-notify[9760]: Version 1.3.2 starting
Mar 18 22:17:58 localhost sm-notify[9760]: Already notifying clients; Exiting!
Mar 18 22:18:00 localhost sshd[9816]: Server listening on 0.0.0.0 port 22.
Mar 18 22:18:00 localhost sshd[9816]: Server listening on :: port 22.
Mar 18 22:18:00 localhost cron[9870]: (CRON) STARTUP (V5.0)
Mar 18 22:18:00 localhost su[9899]: Successful su for fitzcarraldo by root
Mar 18 22:18:00 localhost su[9899]: + /dev/console root:fitzcarraldo
Mar 18 22:18:00 localhost su[9899]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost dbus[7763]: [system] Activating service name='org.freedesktop.RealtimeKit1' (using servicehelper)
Mar 18 22:18:01 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully called chroot.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully dropped privileges.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully limited resources.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Watchdog thread running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Canary thread running.
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_unix(kde:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_ck_connector(kde:session): nox11 mode, ignoring PAM_TTY :0
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] sink.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] source.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module-jackdbus-detect.c: Unable to contact D-Bus session bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module.c: Failed to load module "module-jackdbus-detect" (argument: "channels=2"): initialization failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Module load failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost su[9899]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9964]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9966]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9968]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:15 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
Mar 18 22:18:15 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UPower'
Mar 18 22:18:17 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Mar 18 22:18:17 localhost udisksd[10120]: udisks daemon version 2.1.4 starting
Mar 18 22:18:17 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Mar 18 22:18:17 localhost udisksd[10120]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Mar 18 22:18:19 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:16:fa:25:28:01:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 PROTO=2 
Mar 18 22:18:54 localhost hp-systray[10453]: hp-systray[10453]: error: option -s not recognized
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Successfully made thread 10469 of process 10469 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:55 localhost pulseaudio[10469]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Successfully made thread 10485 of process 10485 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:56 localhost pulseaudio[10485]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:19:04 localhost polkitd[7911]: Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.52 [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Mar 18 22:19:10 localhost su[10569]: Successful su for root by fitzcarraldo
Mar 18 22:19:10 localhost su[10569]: + /dev/pts/0 fitzcarraldo:root
Mar 18 22:19:10 localhost su[10569]: pam_unix(su:session): session opened for user root by fitzcarraldo(uid=1000)
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Mar 18 22:20:01 localhost cron[10670]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

In the cases when NetworkManager activates a connection correctly and there is no invalid second eth0 connection, the log contains a message like the following:

Mar 16 22:23:47 localhost NetworkManager[6688]: <info>  Auto-activating connection 'eth0'.

Notice there is no such message in the message log above.

The only way I can be sure of preventing NetworkManager creating an invalid second eth0 connection is to disable IPv6 system-wide by uncommenting the line ‘alias net-pf-10 off‘ in the file /etc/modprobe.d/aliases.conf.

So, to me, this looks like a bug in NetworkManager 1.0.0 (I have been experiencing it since Version 0.9.10.0).