Re:An almost perfect rsync over SSH backup script
by scottlamb on Friday February 25, 2022 @02:16PM
(#30471002)
> Using pipefail makes it more likely your script will fail unexpectedly and without a known cause. You have to check PIPELINE to see which command in a string of pipes failed and then report on it. This is often pointless, because usually just checking the output of the last pipe will tell you whether you got what you wanted.
Really? In this script's "ps aux | grep -c rsync" for example, if "ps" fails, you'll just get 0 without the grep failing.
(Speaking of that line: chasil's completely right that it's much better to use "flock" than "ps" for locking...)
Re:An almost perfect rsync over SSH backup script
by mekster on Saturday February 26, 2022 @07:37PM
(#30483913)
> There are cases where you don't want -e enabled, such as when you want to make sure your script makes the best attempt to continue operating even through unknown failures.
You don't let go of -e for that.
dont_mind_failure || true
important_process
Re:An almost perfect rsync over SSH backup script
by 0xbadcafebee on Wednesday March 02, 2022 @10:15AM
(#30528260)
There are scripts where you don't want any failure to kill the script. You would have to wrap nearly every line in that kind of exception handling, and if you miss one, the script fails. It is much simpler to omit -e in that case
There are cases where you don't want -e enabled, such as when you want to make sure your script makes the best attempt to continue operating even through unknown failures.
Using pipefail makes it more likely your script will fail unexpectedly and without a known cause. You have to check PIPELINE to see which command in a string of pipes failed and then report on it. This is often pointless, because usually just checking the output of the last pipe will tell you whether you got what you wanted.
When your script does fail unexpectedly, you'll want to re-run it with at least tracing enabled, so the third line should be something like