On 5/18/20 5:13 AM, hw wrote:
Hi,
after trying sshfs to mount a remote file system on a server with the result
that sshfs will sooner or later get stuck and require a reboot of the client,
I'm fed up with it and am looking for alternatives.
So next I would like to use NFS over a VPN connection instead. To minimize
the instances of the NFS mount getting stuck, it might be helpful to use
autofs.
What happens when the mount is stuck because the connection is down and autofs
figures the idle timeout has expired and tries to unmount the remote file
system?
Nothing good, and bad things happen before this.
What happens when I put the client to sleep by suspending to RAM? Will autofs
automatically unmount first, or will the server have to deal with a client
that has apparently gone away and might re-appear later in unexpected ways?
This is the mechanism that I use to try to mitigate this on our systems:
This triggers on suspend type events:
# cat /etc/systemd/system/suspend.target.wants/offnet.service
[Unit]
Description=Unmount all NFS mounts before disconnecting from network
Before=systemd-hibernate.service
Before=systemd-shutdown.service
Before=systemd-suspend.service
[Service]
ExecStart=/usr/local/sbin/offnet
Type=oneshot
[Install]
WantedBy=hibernate.target
WantedBy=shutdown.target
WantedBy=suspend.target
----
This triggers when you bring down a vpn connection with NetworkManager:
# cat /etc/NetworkManager/dispatcher.d/pre-down.d/autofs
#!/bin/bash
if [ -x /usr/bin/logger ]; then
LOGGER="/usr/bin/logger -s -p user.notice -t $0"
else
LOGGER=echo
fi
[ -z "${DEVICE_IP_IFACE}" ] && exit
# Unmount NFS and shutdown autofs if we are shutting down the last
ethernet device or exiting vpn
if [ "$(/usr/bin/nmcli --terse --fields 'device,type' c show --active |
grep -v "^${DEVICE_IP_IFACE}:" | grep -c :802-)" -eq 0 -o \
"${DEVICE_IP_IFACE}" = tun0 ]; then
$LOGGER "Unmounting NFS/CIFS directories"
/usr/local/sbin/offnet
$LOGGER "Performing autofs pre-down stop"
systemctl stop autofs.service
fi
----
# cat /usr/local/sbin/offnet
#!/bin/bash
. /etc/init.d/functions
# __umount_loop awk_program fstab_file first_msg retry_msg retry_umount_args
# awk_program should process fstab_file and return a list of fstab-encoded
# paths; it doesn't have to handle comments in fstab_file.
__umount_loop() {
local remaining sig=
local retry=3 count
remaining=$(LC_ALL=C awk "/^#/ {next} $1" "$2" | sort -r)
while [ -n "$remaining" -a "$retry" -gt 0 ]; do
if [ "$retry" -eq 3 ]; then
action "$3" umount $remaining
else
action "$4" umount $5 $remaining
fi
count=4
remaining=$(LC_ALL=C awk "/^#/ {next} $1" "$2" | sort -r)
while [ "$count" -gt 0 ]; do
[ -z "$remaining" ] && break
count=$(($count-1))
usleep 500000
remaining=$(LC_ALL=C awk "/^#/ {next} $1" "$2"
| sort -r)
done
[ -z "$remaining" ] && break
kill $sig $(/sbin/fuser -m $remaining 2>/dev/null |
sed -e "s/\b$$\b//g") > /dev/null
sleep 3
retry=$(($retry -1))
sig=-9
done
}
__umount_loop '$3 ~ /^nfs/ && $3 != "nfsd" && $2 != "/" {print $2}' \
/proc/mounts \
$"Unmounting NFS filesystems: " \
$"Unmounting NFS filesystems (retry): " \
"-f -l"
__umount_loop '$3 ~ /^cifs/ && $2 != "/" {print $2}' \
/proc/mounts \
$"Unmounting CIFS filesystems: " \
$"Unmounting CIFS filesystems (retry): " \
"-f -l"
Is there a way to tell NFS to retry an operation _now_ after the connection
went down and came back, rather than having to wait for a possibly rather long
time?
Not that I'm aware of.
Is there a better alternative for mounting remote file systems over unreliable
connections?
I would second the recommendation for SMBv3/CIFS for a fault tolerant
remote file system.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion@xxxxxxxx
Boulder, CO 80301 https://www.nwra.com/
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
