You are not logged in.
Hi,
I have a holiday freeze issue with my laptop.
The system started normally but would freeze as soon as I connected to WIFI after logging in. I could not even change to a text console.
I could narrow this down to my NFS shares. When I activated the VPN to my home server on the text console before logging in to Gnome everything was fine. Now I have disabled the two NFS shares in my fstab and everything is fine as well.
This issue has popped up for me quite sudden. The setup is not new and it was never an issue before. Was there a change that Gnome does not simply give up? There are lots of failed mount attempts in the journal until the necessary hard reset.
How do I tell Gnome to give up on unreachable resources?
Cheers,
Torsten
Offline
I have the same issue. I am not sure if this is a new issue or an old bug.
My use case is a bit different. When the NFS mounts are disrupted (e.g. when I reboot the machine that hosts the NFS volumes)m then Gnome freezes and there's nothing I can do (except get out of it). When the NFS-hosting machine is up again, things are again as usual.
A google search brings many pages describing a similar situation of both KDE and Gnome, with only solution to unmount NFS before doing something to the host machine, which is not practical if you don't know in advance that the NFS machine is (going to be) down.
Any hints on how to address this issue welcomed ![]()
Offline
x-systemd.automount,x-systemd.device-timeout=10,noatime,soft,bg?
Offline
I was missing the "soft" and "bg" options in fstab. Unfortunately adding them did not solve the issue. My complete options are:
rw,user,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min,soft,bg,comment=x-gvfs-showCheers, Torsten
Offline
Does "comment=x-gvfs-show" trigger this?
What if you set "retry=0"?
Since you're automounting the share on access only, it would seem that gnome™ (nautilus? tracker? sth. specific?) tries very hard to access a file there.
Do you btw. mount the share by IP or domain?
Is there a route to the (wrong) host when NFS isn't available?
Offline
I made some experiments. "comment=x-gvfs-show" is necessary for the mount to appear in Nautilus. But removing this and/or "retry=0" does unfortunately not solve the problem.
The mounts use the IP. If I unmount the shares before deactivating WIFI it does not lock up. Clicking on the unmounted share in Nautilus gives an error but deactivating WIFI with a mounted share locks up the computer. The shares are active after login in Nautilus even though they have the "noauto" flag.
Something must have changed between August 2023, when everything worked and February 2024 when I noticed this issue.
Cheers,
Torsten
Offline
Clicking on the unmounted share in Nautilus gives an error but deactivating WIFI with a mounted share locks up the computer.
Offline
Unfortunately not. The hook scripts will only run when I intentionally disconnect WIFI. A sudden failure is not covered.
I checked if it might be the "bg" option as mentioned here:
https://www.freedesktop.org/software/sy … html#fstab
but no luck.
I have to check if the computer locks up when I shut down the server and try to use ssh to investigate. Or install a simpler window manager like Sway to check if it is systemd or Gnome. I suspect Gnome.
Cheers,
Torsten
Offline
You can just test whether "ls /path/to/lost_nfs_share" locks/freezes or behaves (returns after timeout)
You're not getting any dispatcher event on the loss?
https://man.archlinux.org/man/NetworkMa … spatcher.8
Does the remote host drop out?
Does nautilus handle softerr better than soft (ETIMEDOUT instead of EIO)?
Offline
I still suspect Gnome. The issue disappeared today with an update to Gnome 46.
Cheers,
Torsten
Offline
Same issue. It has been so annoying in the past years, and I created a daemon script to automatically detect a freeze & umount.
HMS_GOOD=0
HMS_BAD=1
# Function to check if hms.r is reachable
check_reachability_i() {
if ping -c 1 hms.r &> /dev/null; then
return $HMS_GOOD # Host is reachable
else
return $HMS_BAD # Host is unreachable
fi
}
check_reachability() {
for i in {1..20}; do
check_reachability_i && return $? ; sleep 0.2
done
return $HMS_BAD
}
check_mounted() {
# Warning: df -T might hang forever if NFS is offline!
df_res=$(df -T) || return $HMS_GOOD # nfs io error. Return mounted=1
echo "$df_res" | grep nfs && return $HMS_GOOD || return $HMS_BAD
}
#prev_stat=$HMS_GOOD
while true; do
check_reachability
net_stat=$?
if [ $net_stat = $HMS_BAD ]; then
# Bug fix: if network unavailable, check_mounted might hang.
umount -f -l /home/recolic/nfs
else
check_mounted
nfs_stat=$?
if [ $nfs_stat = $HMS_BAD ]; then
mount -o bg,intr,soft,timeo=1,retrans=1,actimeo=1,retry=1 hms.r:/ /home/recolic/nfs
fi
fi
sleep 2 # Sleep for 3 seconds
doneOffline
That will however not cover cases where the remote host stays up but the nfs server drops out.
Does nautilus handle softerr better than soft (ETIMEDOUT instead of EIO)?
Alternatively, If you've surrendered to gnome anyway, you might also use https://archlinux.org/packages/extra/x86_64/gvfs-nfs/
Offline