znapzendzetup should not fail without proper return code

[marcelhuberfoo]

When issuing znapzendzetup commands, calls to non-existent plans, datasets etc. should exit with a proper non-zero exit code. Instead, the return/exit code is always zero but an 'ERROR: <message>' to the console is printed for some operations which is quite useless for automated processing of commands.

It would be helpful if I could use the list command to check if a backup set/config exists yet for a specified dataset.

Operations examples which all exit with code 0 (=true) for a filesystem not configured for a backup plan yet:

~ $ znapzendzetup edit SRC rootpool/DATA/backed
ERROR: backup set for rootpool/DATA/backed does not exist

~ $ znapzendzetup edit rootpool/DATA/backed
ERROR: cannot get backup config

~ $ znapzendzetup list rootpool/DATA/backed
NOTE: if you have modified your configuration, send a HUP signal
(pkill -HUP znapzend) to your znapzend daemon for it to notice the change.

~ $ znapzendzetup delete rootpool/DATA/backed
NOTE: if you have modified your configuration, send a HUP signal
(pkill -HUP znapzend) to your znapzend daemon for it to notice the change.

[saurabhnanda]

This is also true for znapzend itself. I have the following in a bash script:

## want the script to fail if any command fails
set -e

## omitting commands to take a full db backup

## commands to take a snapshot and send it for offsite backup 
## once full-db backup completes successfully

zfs_snapshot_time=$(mktemp)
temp_files+=($zfs_snapshot_time)

# HOWEVER, the following command never fails even if sending the snapshot
# to offsite server fails.
/usr/bin/time -o $zfs_snapshot_time --format '%E %P' /opt/znapzend/bin/znapzend --runonce=backuptank/barman
echo "COMPLETED: ZFS Snapshot and sending to offiste (mm:ss.ms  %cpu) = ($(cat $zfs_snapshot_time))"

[crabique]

Agree, the error handling could be improved. I'm getting mbuffer errors during znapzendsetup:

*** WARNING: executable '/usr/bin/mbuffer' does not exist on zfs-backup@backups.local

But what it actually means is that it couldn't resolve DNS and access the destination via SSH control plane.. And since it's the only destination, it's not actually a warning, but a should-be failure.

Would be nice if those errors were handled and the return code reflected the failure, at least 1 for a hard fail so that it can be || exit 1ed.

[spartan117aut]

I'm also having this issue. This is how I execute znapzend in my script:

/usr/local/bin/znapzend --debug --runonce=tank/git --logto=/var/log/znapzend.log

It returns 0 even if the destination is not available via ssh...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.