Fix CMOS Battery Issue with NTP: the NetworkManager Edition

While in the previous article, I described a solution to trigger a script when the network goes up. This works on most server Linux setups but it does not work if you are using NetworkManager. NetworkManager has a different way of doing this. If you are not sure whether you are using NetworkManager, consider this: if you are using a wireless network and configuring it using an applet in the task bar or through a GUI program, it's likely that you are using NetworkManager. That and the fact that the script in my previous article didn't work.

NetworkManager applet (Photo credit: Wikipedia)

NetworkManager can still do it. It can run scripts after a network interface is connected or disconnected. It's just not apparently forthright about it. But first a little clarification. In Linux parlance, when a network is connected, it is known as "a network being brought up". This is because the network interface state is changed from DOWN to UP.  And vice versa. When talking about network connections, both set of terms are used interchangeably.
NetworkManager offers this feature through a mechanism called a dispatcher. Basically, the dispatcher looks into the /etc/NetworkManager/dispatcher.d directory and run scripts saved in there. Scripts start with a two digit number that determines the order they are run. The scripts are passed two parameters from the main NetworkManager system. They are the network interface that was connected or disconnected and whether it was connected or disconnected.
In my case, I didn't care which network interface it was but it had to be just connected. So the script looked something like this.

#!/bin/sh
#
# Run ntpdate when network interface goes up using NetworkManager
#
export LC_ALL=C
if [ "$2" = "up" ]; then
        /usr/sbin/ntpdate -u pool.ntp.org
        logger Updated time due to network interface going up
fi

Save the file as 10-ntpdate.sh and change it's attributes to be executable. Drop that into the /etc/NetworkManater/dispatcher.d directory. That's it.

It took some time to figure this out because searches didn't show any direct result. After reading through this bugfix entry for Fedora there was a reference to this article in RedHat Magazine. The article explained the NetworkManager mechanism in some detail. Once I figured out that the method was called dispatcher, Googling it pointed to articles by the Arch community or related to the Arch distro. If you are not familiar with Arch and it's community, it is the closest thing to all of the stereotypes people normally associate with Linux users. It is harder to install, everything is done manually and you have to be somewhat of expert to get it running. So by the fact that dispatcher articles is written by Arch users, it is assumed that it is pretty deep, technically. Which it isn't, really.
NetworkManager's claim to fame is the ability to associate network interfaces and network-related services to the user. This is in contrast to the standard way of Linux associating them to the system. This was supposed to be a more flexible way to handle user-specific, ad-hoc services like wireless network connections. It is an option for desktop distros to manage network connections as opposed to the server-friendly way standard Linux distros handle this by default (from now on called as the default way).  This way, different users can store specific network access credentials and configurations separately from other users. Different users using the same laptop may connect to different wireless networks or access network services with different logins. The net effect is (pun intended) a more Windows-like approach to network management. Which is not necessarily a good thing.
NetworkManager has the unintended effect of making what was quite a known feature into an obscure one. It did so by doing so much, especially on the GUI side. The feature to run scripts has always been there but there are no GUIs to configure them. And since NetworkManager does a lot using the GUI, the assumption is that the feature is an obscure one.
So this is the dilemma of the desktop Linux. Convenience obscure usefulness.