Bug in /etc/NetworkManager/dispatcher.d/20-chrony?

(Hope this is the right place to post this…)

I believe I’ve found a bug in the copy of /etc/NetworkManager/dispatcher.d/20-chrony that comes with Leap 15.5. Here’s the file in its entirety:

# This is a NetworkManager dispatcher / networkd-dispatcher script for
# chronyd to set its NTP sources online or offline when a network interface
# is configured or removed

export LC_ALL=C


# For NetworkManager consider only up/down events
[ $# -ge 2 ] && [ "$2" != "up" ] && [ "$2" != "down" ] && exit 0

# Note: for networkd-dispatcher routable.d ~= on and off.d ~= off

$chronyc onoffline > /dev/null 2>&1

exit 0

I believe that ... && exit 0 line does the following:

  1. If there are two or more arguments, AND
  2. The second argument isn’t “up”, AND
  3. The second argument isn’t “down”, THEN
  4. bail.

This means that if any of the following is true, then $chronyc onoffline is executed:

  • There’s zero or one arguments
  • The second argument is “up”
  • The second argument is “down”

Did the author really want $chronyc onoffline to be executed whenever 20-chrony is given 0 or 1 arguments? If not, then shouldn’t that first term be omitted?

In this case, I think you’ll be better assisted by bug reporting process.

Thanks: submitted: 1227534 – Bad bash expression in NeworkManager script 20-chrony

1 Like

Connectivity change events invoke dispatcher scripts with a single argument and this action is appropriate. NetworkManager does not invoke scripts without arguments.

(Rewriting my previous response… Stand By…)

I took another look at the NetworkManager dispatcher:

Each script receives two arguments, the first being the interface name of the device an operation just happened on, and second the action. For device actions, the interface is the name of the kernel interface suitable for IP configuration. Thus it is either VPN_IP_IFACE, DEVICE_IP_IFACE, or DEVICE_IFACE, as applicable. For the hostname action the device name is always “none”. For connectivity-change and dns-change it is empty.

So the script is always called with two arguments, meaning this term will never fail, and won’t cause problems in real life. But it’s confusing (especially to a noob such as I) as it implies the wrong thing, and if the NetworkManager script API ever changes, this latent problem may actually cause trouble. In any case, code that serves no purpose should be removed.

The issue is reported; they’ll handle it as they see fit.