The dispatcher service has to be enabled.

Hello Jan

Thanks for this hint. After enabling NetworkManager-dispatcher.service scripts in /etc/NetworkManager/dispatcher.d/ are executed.

However I am facing a new problem. My 30_sshfs script performs several sshfs mounts when a network interface goes up. Initially the mounts all appear (sshfs is started properly) but as soon as /usr/lib/networkmanager/nm-dispatcher.action terminates (after a few seconds), all sshfs processes are terminated as well and the mounts are gone.

According to pstree there is no parent/child relationship between nm-dispatcher.action and the sshfs processes that would explain this behavior.

One difference I found between NetworkManager 0.9.8.0-3 and 0.9.8.2-1 is the output of the "id" command when called in 30_sshfs:

0.9.8.0-3: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
0.9.8.2-1: uid=0(root) gid=0(root) groups=0(root)

Regards, Peter.

This is the expected behavior because systemd will not let the service leave any processes around after it exits. Two possibilities:

a) Add KillMode=process to the dispatcher service to evade the killing spree

b) Start another unit from the dispatcher (via systemctl):

Add the sshfs mounts to fstab:
sshfs#user@hostname:/remote/dir1 /foo/bar fuse noauto,_netdev
sshfs#user@hostname:/remote/dir2 /foo/baz fuse noauto,_netdev

Run "systemctl daemon-reload" to reload fstab, then set up the dispatcher script to run "systemctl start /foo/bar /foo/baz".

Hello Jan

Once again thanks for your advice.

I tried b) because not changing the unit file that comes with the Arch package seemed cleaner. Mounting works fine but "systemctl stop /foo/bar" in the "down" case of the dispatcher script leads to a hanging umount call. umount works from the command line but that is not an option.

Method a) works fine with the downside of the unit file change. So each time the upstream unit file changes a merge operation is necessary to preserve my modification.

Regards, Peter.