0

I have a little data collector, a Raspberry Pi Zero W, which, on boot, mounts a remote folder on mnt using sshfs. The data transfer is effected using a cp command, e.g., cp device file & where device is local and file is in the remote folder. This is intended to be an infinite loop. If power to the Pi fails the process restarts when power returns. But what if the server goes down during the copying? I'd like to then loop into a reboot until copying resumes. But how can I tell, from the pi, when the server is out?

Dave Stevens
  • 11
  • 1
  • The server, network, SSH connection, or sshfs could fail at any point. There may be an error, or things could just wedge. Also the `cp` could fail if the disk fills up or under various other cases. I'm not sure how `device` is changing, but for an unreliable copy I'd probably try `rsync --partial ...` and have a script around that to try to get the sshfs up instead of an expensive reboot loop. – thrig Jul 19 '22 at 04:29
  • where's the infinite loop here? – ilkkachu Jul 19 '22 at 07:38
  • You'd almost certainly be better off with `rsync` instead of `cp` over `sshfs`. Assuming you can install it on the remote end, that is – roaima Jul 19 '22 at 08:12

1 Answers1

0

There's a number of problems with this:

  • cp is meant to copy files, not streams. Every time the pi reboots, it will restart the copy, zeroing out any previous data. If this isn't what you want, you might be better off with something like cat device >> file or maybe dd
  • sshfs is not very robust. When the server reboots, the sshfs connection will die and not resume without something actively restarting it, and the cp will die. NFS is designed to handle this situation, and would just pause until the server is back up and then resume as if nothing happened. Even using just ssh by itself might be better than sshfs.
  • Depending on what you are doing, you might be better off setting up a service of some sort on the server to collect the data rather than using filesystem semantics. Netcat on both ends might be better, but even that is less robust than it could be.

Without more details on why you are doing this and what your goals are, it's difficult to give better advise.

user10489
  • 5,834
  • 1
  • 10
  • 22
  • a number of problems... – Dave Stevens Jul 19 '22 at 04:39
  • data stream is non-replicable, live atmospheric conditions. measuring particle pollution levels and saving the data of the server for analysis later, the main aim is to reliably get live data saved on the server, everything else will take place there. The data file naming scheme has worked well for about a year but the pi platform allows size reductions and refactoring, more samplers will enable more errors. Thx, more questions? – Dave Stevens Jul 19 '22 at 04:49