NetworkManager dispatcher functionality

Inside the man pages for NetworkManager, it is indicated that:

DISPATCHER SCRIPTS
NetworkManager will execute scripts in the /etc/NetworkManager/dispatcher.d directory or subdirectories in alphabetical order in response to network events. Each script should be a regular executable file owned by root.
Furthermore, it must not be writable by group or other, and not setuid.

   Each script receives two arguments, the first being the interface name of the device an operation just happened on, and second the action.
   The actions are:
   pre-up
       The interface is connected to the network but is not yet fully activated. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-up.d directory, and NetworkManager will
       wait for script execution to complete before indicating to applications that the interface is fully activated.
   up
       The interface has been activated.
   pre-down
       The interface will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and
       NetworkManager will wait for script execution to complete before disconnecting the interface from its network. Note that this event is not emitted for forced disconnections, like when carrier is lost or a wireless
       signal fades. It is only emitted when there is an opportunity to cleanly handle a network disconnection event.
   down
       The interface has been deactivated.

First of all: there are no directories such as /etc/NetworkManager/dispatcher.d/pre-up.d and /etc/NetworkManager/dispatcher.d/pre-down.d.
There are also some other issues. As a reproducible test, let’s consider the following script (to be chmod 755 and put inside /etc/NetworkManager/dispatcher.d):

> cat netStatusScript 
#! /bin/sh

echo "$(date) netStatusScript: $0]:$1]:$2]" >> /tmp/netStatusScript.log

If I issue (as root):

> systemctl stop network.service
> systemctl start network.service

I get the following:

> tail /tmp/netStatusScript.log
Tue Jan  5 15:54:30 CET 2016 netStatusScript: [/etc/NetworkManager/dispatcher.d/netStatusScript]:[eth0]:[up]

This signifies that only during “up” the script is executed: all other events (pre-down, down, and pre-up) do not trigger the custom script.
Moreover, if I manually create the /etc/NetworkManager/dispatcher.d/pre-down.d directory and put the script into it, as indicated in the man page, no action is triggered on stop/start of the network.

This behavior has been verified on openSUSE 42.1.

Information for package NetworkManager:
---------------------------------------
Repository: openSUSE-leap/42.1-Oss
Name: NetworkManager
Version: 1.0.6-1.2
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date

Is it a bug? How can I made the script triggered by, for instance, the pre-down event?
Thanks in advance for your suggestions.

On TW I get pre-down if I explicitly deactivate connection; I do not get it on shutdown or sleep events indeed. Manual suggests that pre-down may not be always emitted.

I guess you have better chance on NetworkManager mailing list. Or at least on Networking forum here (this is hardly related to programming).

Perhaps explicitly stopping or even restarting NetworkManager.service before suspend might help with getting the dispatcher script triggered.

As a quick test I created NM.sh in /usr/lib/systemd/system-sleep

#!/bin/sh

if systemctl --quiet is-enabled NetworkManager; then
  case $1/$2 in
    pre/*)
      systemctl restart NetworkManager
      ;;
    post/*)
      ;;
  esac
fi

That got my test.sh dispatcher script executed, although I’m only doing

#!/bin/bash
echo "$(date) stopped" >> /tmp/ftp_archivio_stop.log
sleep 5

Please close the thread.
The full control of the NM status is not guaranteed (at least for the scopes that I have in mind), as correctly pointed out by arvidjaar:

Manual suggests that pre-down may not be always emitted.

There’s ongoing debate on the architecture of such functionality
https://bugzilla.gnome.org/show_bug.cgi?id=701242
Thank you all for the contributions.
Michele.