I was wondering if it would be possible to add a -qq option to rclone to make it stop producing error output like:
…
2018/11/27 06:41:12 ERROR : Attempt 1/3 failed with 1 errors and: not deleting files as there were IO errors
2018/11/27 06:43:46 ERROR : Attempt 2/3 succeeded
I don’t want to send all the stderr to /dev/null and want error information on “hard errors”, i.e. in this case that would be a failure on the third attempt, but I consider the failures before the retry limit is exceeded to be a “soft error”. In other words, I’m not interested in this error information unless the number of retries has been exceeded and rclone has exited before successfully completing what it was attempting to do.
Does that make sense? I hope so.
I’ve looked through the documentation for rclone and cannot see that what I’m requesting is possible at the moment.
You are right you can’t achieve what you want at the moment.
Are you saying you don’t want any of the intermediate ERROR messages before the retry? Or to suppress the ERROR messages unless it is on the last retry?
I am suggesting the latter, i.e. error messages would be suppressed unless rclone fails on the last retry.
My thinking is that if rclone succeeds on or before the last retry, you could say that really it has actually succeeded during that invocation (the “soft error”), whereas if it fails on the last retry then it’s a “hard error” because at that point rclone gives up on that invocation and will not complete the operation at that time. In the first case the error information would be redundant to a lot of people if the operation eventually succeeds, but in the second case you would probably want to know that it had actually failed permanently, which could then allow you to take remedial action such as increasing the number of retries.
In my use case, I’m running rclone hourly via cron. I get a fair few messages every day that are the output from rclone telling me it has failed on the first/second attempt, but succeeded on the second/third attempt. I want to see any “hard error” issues, but the “soft error” issues are just informational noise that’s of no real importance (to me).