FS#35793 - [networkmanager] Upgrade breaks execution of dispatcher.d scripts
Attached to Project:
Arch Linux
Opened by Peter Klotz (p.klotz) - Friday, 14 June 2013, 20:01 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 15 June 2013, 14:41 GMT
Opened by Peter Klotz (p.klotz) - Friday, 14 June 2013, 20:01 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 15 June 2013, 14:41 GMT
|
Details
Description:
Upgrading from NetworkManager 0.9.8.0-3 to 0.9.8.2-1 breaks execution of scripts in /etc/NetworkManager/dispatcher.d/ The script fulfills all permission requirements according to the manpage: -rwx------ 1 root root 1078 Jun 14 21:25 30_sshfs Steps to reproduce: Use this simple script to test: ----------------- #!/bin/bash echo "script called" >> /tmp/NetworkManager.txt ----------------- NetworkManager 0.9.8.0-3 writes /tmp/NetworkManager.txt, 0.9.8.2-1 does not. |
This task depends upon
Closed by Jan Alexander Steffens (heftig)
Saturday, 15 June 2013, 14:41 GMT
Reason for closing: Works for me
Saturday, 15 June 2013, 14:41 GMT
Reason for closing: Works for me
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.
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".
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.