Best way to avoid a reboot when network goes down during an ssh mount

levi · 2020-07-26 19:34:14

I have a server that I use to preprocess my videos that I download from youtube and other places for display on my local machine which runs Arch32 (my server is an old desktop chassis that's just about capable of running arch64 so that's what I use there). Therefore I do an ssh mount to connect to the remote server (in a spare room) that contains my preprocessed videos.

However, the network on this machine is currently supplied via a TP-Link little wifi USB nubbin which identifies as a ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter under lsusb. That behaves a lot better under a newer kernel than it did when I first used it, but it does now just stop responding every few days (previously the single light on it would go out, but these days it pretends it's still connected even when to all other evidence it ain't).

Problem is that if I'm connected to an ssh mount when this glitch happens, the mount becomes effectively unusable going forward until I reboot. I've not yet even found a way to kill processes that are trying to connect to it, either using killall or kill with a pid. If I'm actively rsyncing across a video file when it goes down, I have to avoid using that terrminal window. I may be able to mount a new mount in a different folder, but I've not tried that yet.

I guess on writing this, that turns out to be the next thing to try (once I remember how), but the question remains how I can kill processes that are locked on a not responding network connection. To reboot pretty much in any case always feels like I'm giving in.

deep42thought · 2020-07-27 17:11:20

You can kill harder with -9 as parameter to kill - but in my experience, this does not work for processes which wait for i/o. Why don't you use rsync directly via network? I think a combination of `umount -l` and a new `mount ...` might resurrect your mount (but obviously will not help hanging programs).

hth,
deep42thought

levi · 2020-07-27 20:42:29

Yes, I was using -9 with killall and kill with a pid, but as you predicted that doesn't do anything when it's not actually running. I'm not honestly sure I've ever tried an umount; probably I did, but I can't remember what it said in response, but I do recall that when I tried to mount -o remount it told me it was a bad mount point. The man page for the -l option of mount suggests the mount point won't be recoverable afterwards, but anything is worth a try I guess.

I recall I used to rsync directly, but found the long command lines somewhat unreliable in practice. A rsync from a remote folder on the local file system requires less typing and less extraneous punctuation, so was seen as an improvement at least while I has more reliable networking. It isn't actually all that flakey at present and the situation above only happens at most about once a week, and what happened to make me post this where it falls over in the middle of transferring a file is even more rare of an occurrence, since I can't actually recall that happening before.

deep42thought · 2020-07-28 12:44:08

Ocassionally, I see something similar (e.g. when I reboot a middle-machine). I think, `umount -l` ("lazy") works in this case, the only caveat is to not use tab-auto-complete, because if you hit it once to often, your prompt will freeze, too

levi · 2020-07-28 18:51:58

I generally find my prompt freezes when even trying to tab complete the second and final path to the mount point, no idea why. I used rsync directly yesterday to grab my videos, without mounting a sshfs mount point first. I had a bit of trouble getting a file that had square brackets in it, and I had to unlock my ssh key for each video, rather than just the once when I mount it, but other than that it's not too bad. and worth practising.

deep42thought · 2020-07-28 18:57:45

The autocomplete freezes for me "one early", too. Probably, it tries to retrieve some properties (e.g. whether it's a symlink, file or directory) and thus tries to access the sshfs.
rsync needs double quoting - one for the shell on your end and one for the shell on the other end. Usually, I simply nest " and '

rsync user@host:"'remote/path with spaces/file'" 'local/path with spaces/'

regards,
deep42thought

levi · 2020-07-28 22:05:25

Ah, I'd tried escaping the bash active characters. Maybe double escaping them would have worked, but I've hit situations like that were both single escaping and double escaping fail in different ways in different parts of the program. I should have tried quoting, but instead I selected the file using a different part of the filename that didn't use any funny characters.

Arch Linux

#1 2020-07-26 19:34:14

Best way to avoid a reboot when network goes down during an ssh mount

#2 2020-07-27 17:11:20

Re: Best way to avoid a reboot when network goes down during an ssh mount

#3 2020-07-27 20:42:29

Re: Best way to avoid a reboot when network goes down during an ssh mount

#4 2020-07-28 12:44:08

Re: Best way to avoid a reboot when network goes down during an ssh mount

#5 2020-07-28 18:51:58

Re: Best way to avoid a reboot when network goes down during an ssh mount

#6 2020-07-28 18:57:45

Re: Best way to avoid a reboot when network goes down during an ssh mount

#7 2020-07-28 22:05:25

Re: Best way to avoid a reboot when network goes down during an ssh mount

Board footer