Any warning over SSH leads to "subvolume fetch failure" of remote targets

[RomuloPBenedetti]

Is it normal? I've been able to solve my warnings and silence my server, but maybe it is a good idea to mention it one of ssh examples?

[digint]

Not sure what you mean by "warning over ssh". What warnings are you talking about exactly?

[RomuloPBenedetti]

For example, in my case, it was about a path in PATH that did not exist, a warning that was presented in every SSH connection. But I believe that any echoed text can lead to it as #25 pointed a similar case.

[boerwastaken]

When #179 was fixed, SSH warnings got silenced. But it seems you're referring to output generated in the login shell, yes that would break the command output parser. Best is to make sure the systems you SSH into properly discern between interactive and non-interactive logins, and hush for the non-interactive ones. The alternative is to make the btrbk parser ignore anything before a certain magic header in the remote's btrfs command output, but that's prone to false positives.

[digint]

btrbk always runs ssh with a command, so your remote shell should always be in non-interactive mode. This does not mean that the shell does nothing, actually it does a lot of things.

Best is to make sure the systems you SSH into properly discern between interactive and non-interactive logins, and hush for the non-interactive ones.

e.g. if you are using bash, the first lines in ~/.bashrc should look like this (except you really want the shell to do your magic stuff):

if [[ $- != *i* ]] ; then
    # Shell is non-interactive.
    return
fi

Also make sure that $BASH_ENV is not set, or that the script called there is also silenced.

The alternative is to make the btrbk parser ignore anything before a certain magic header in the remote's btrfs command output, but that's prone to false positives.

This is probably not going to happen. btrbk requires a sane environment, and having chatty non-interactive shells is not sane in my opinion. E.g. having invalid $PATH is clearly something that should be fixed.

[RomuloPBenedetti]

I agree, and understand that a chatty non-interactive shell is not sane, but I got pretty confused as the error did not point to the cause, maybe some explanation on FAQ or at Setting Up SSH, can avoid doubts.

[digint]

[...] maybe some explanation on FAQ or at Setting Up SSH, can avoid doubts.

Do you have some suggestions for this? How exactly did the errors look like with your "dirty" ssh configuration?

[RomuloPBenedetti]

the error is pretty much the same of #25

WARNING: Skipping subvolume "hostname.local:/path/to/backup/dir" : Failed to fetch subvolume detail: finding real path for 'hostname.local:/path/to/backup/dir', No such file or directory

Something like:

Be sure your remote shell startup files, like ~/.bashrc and $BASH_ENV in bash case, don't call commands or scripts that output to the standard output/errors otherwise Btrbk parser will fail with "subvolume fetch failure" error message for targets subvolume. btrbk expects a sane non-interactive shell, what implies a non-chatty shell, probably you want to redirect those output messages to a log file or /dev/null.