Unavailable sshfs mount point = apps freeze for ~10-20 seconds

Soukyuu · 2016-01-21 18:02:21

I have a couple of sshfs mounts to my local server/NAS, today I shut it down for maintenance while one of my linux PCs was on, and now nearly every application hangs for 10-20 seconds after any browsing action.
The mounts are as follows:

myuser@192.168.178.2:/data/SomeShare           /home/myuser/SomeShare       fuse.sshfs      nofail,x-systemd.automount,idmap=user,_netdev,identityfile=/home/myuser/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000,umask=0,reconnect,cache=no,kernel_cache,ciphers=arcfour,compression=no

What I'm used to is the mount point simply returning an error on access and doesn't affect browsing otherwise if it's not mounted.
Is there a way to make it work like that in this case as well?

x33a · 2016-01-22 05:32:28

Maybe give autofs a try?

Soukyuu · 2016-01-22 21:04:13

Doesn't seem like it's going to help me, as the wiki says the following about mounting to a specific folder:

Note: This can cause problems with resources getting locked if the connection to the share is lost. When trying to access the folder, programs will get locked into waiting for a response, and either the connection has to be restored or the process has to be forcibly killed before unmounting is possible. To mitigate this, only use if you will always be connected to the share, and do not use your home folder or other commonly used folders lest your file browser reads ahead into the disconnected folder

Which is exactly the situation I'm in without autofs atm. Is linux really that... un-robust when it comes to losing the connection to a share?

respiranto · 2016-01-23 01:07:15

Is linux really that... un-robust when it comes to losing the connection to a share?

At least sshfs, apparently.
I had similar issues with my local Raspberry Pi sharing /srv, so I switched to editing all the files locally and pushing them via a custom vim command.
Obviously this is not an option for you, but have you tried any other solution, such as NFS?

Soukyuu · 2016-01-23 12:24:24

The same issue happens with samba, it seems to be related to x-systemd.automount. I guess it just stubbornly attempts to mount the share every time something accesses it...

respiranto · 2016-01-23 12:48:37

If it was only, x-systemd.automount, it could be simply disabled.
Though, at least for the connection to my Raspberry Pi, I never had that enabled - 'noauto' was sufficient due to my lesser needs.

However, if you believe this setting to be the culprit, you could test if switching to noauto and automounting the share upon login helps.

Actually I could even imagine, that systemd's automount will help in case the connection is broken by trying to remount the share properly.
I was sometimes forced to kill the sshfs process before being able to remount the shared folder.

By the way:

systemd.automount(5)
       TimeoutIdleSec=
           Configures an idle timeout. Once the mount has been idle for the
           specified time, systemd will attempt to unmount. Takes a
           unit-less value in seconds, or a time span value such as "5min
           20s". Pass 0 to disable the timeout logic. The timeout is
           disabled by default.

Possibly changing this to a lower value may also help.
Though you would probably have to create a custom automount unit.

Soukyuu · 2016-01-23 16:09:34

That only applies for idling, though, not when the mount point is already dead. I've tried setting

x-systemd.device-timeout=
Configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly append a unit such as "s", "min", "h", "ms".

Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file.

But it's not working. I get the same hangs once the mount point dies.

respiranto · 2016-01-23 16:30:33

I thought a missing connection might be count as idling, since no data can be transferred.

By the way, you assumed, x-systemd.automount would try to mount the filesystem, which implies that it has been properly unmounted before.
Is this true?
To me, it sounds rather unlikely, since any process operating on it, i.e. a shell with $PWD inside the filesystem should prevent that. And if there are programs hanging due to this, I suspect they use the filesystem.
Or am I somehow wrong?

Soukyuu · 2016-01-23 19:21:40

Yes, as I wrote in my opening post, the connection to the server the share is located on goes down because it shuts down. So yes, it was mounted successfully, then loses connections.
Starting e.g. dolphin will hang with an empty window until it (or systemd.automount) gives up on trying to mount the share. Attempting to open any shares will result in another freeze. So it doesn't affect just the programs that were already running when the connection went down.

Last edited by Soukyuu (2016-01-23 19:22:25)

respiranto · 2016-01-23 19:35:36

Losing the connection does not imply the proper unmounting of inaccessible remote filesystems.
So, just to confirm, is the filesystem not loger listed in /proc/self/mounts?

Have you tried, whether disabling systemd.automount helps?
E.g. by disabling the associated automount unit, probably home-myUser-someShare.automount?

Soukyuu · 2016-01-24 10:39:19

I removed x-systemd.automount and set noauto. I now have to manually mount the share at every boot, however if the connection goes down, the same thing happens. So it's not related to automount, and probably not a mounting problem per se, but the way sshfs and samba handle a dropped connection.

respiranto · 2016-01-24 10:49:52

So I assume the share is still perceived as mounted by the OS, which means that the only workaround is to forcibly unmount it, by killing the respective sshfs process and possibly regularly `umount'-ing the mountpoint afterwards.

By the way, have you tried x33a's suggestion? It looks promising to me.

Soukyuu · 2016-01-24 10:52:27

I replied to his suggestion, the wiki explicitly states my use case as one causing the same freezes I'm getting now.

respiranto · 2016-01-24 12:17:44

Sorry, I must have somehow skipped your reply.

Oh, and after doing what one should have already done in the beginning, a quick web-search, I found this:
https://serverfault.com/questions/30679 … connection

EDIT: Sorry, it seems like you already use the reconnect option.

Last edited by respiranto (2016-01-24 12:22:36)

Soukyuu · 2016-01-24 21:49:02

Yes, I am. There is no issue with reconnecting once the server is back up, the main problem is the behavior while the server is down.

Arch Linux

#1 2016-01-21 18:02:21

Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#2 2016-01-22 05:32:28

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#3 2016-01-22 21:04:13

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#4 2016-01-23 01:07:15

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#5 2016-01-23 12:24:24

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#6 2016-01-23 12:48:37

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#7 2016-01-23 16:09:34

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#8 2016-01-23 16:30:33

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#9 2016-01-23 19:21:40

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#10 2016-01-23 19:35:36

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#11 2016-01-24 10:39:19

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#12 2016-01-24 10:49:52

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#13 2016-01-24 10:52:27

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#14 2016-01-24 12:17:44

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

#15 2016-01-24 21:49:02

Re: Unavailable sshfs mount point = apps freeze for ~10-20 seconds

Board footer