Hide Forgot
Description of problem: Please backport PR https://github.com/rear/rear/pull/2735 once accepted Upstream. The current evaluation of the scripts is through "eval ${SCRIPT[@]}" which has many drawbacks, in particular when using array variables, each line must be semi-colon terminated or else the rest will be skipped, e.g. PRE_RECOVERY_SCRIPT=( 'multipathd' ) PRE_RECOVERY_SCRIPT+=( 'sleep 10' ) results in executing "multipathd sleep 10" instead of expected "multipathd" then "sleep 10". This enhancement evaluates the scripts item by item, which is more bulletproof and still supports having the script specified as a string variable. Version-Release number of selected component (if applicable): All rear released including 2.6 How reproducible: N/A
Hi, thanks for the PR, I left a comment there. The current behavior is indeed a bit silly, but it seems to be what was intended (except for the handling of whitespace in arguments, which is probably not as intended, and with it the whole justification for using shell arrays disappears). So, I think it is better to introduce new variables with a better-defined behavior, and let the old ones slowly die.
We now have a discussion upstream about other changes of semantics of POST_BACKUP. Would it be acceptable to do just the PRE/POST_RECOVERY part for now? Also, your opinion on whether to run the POST_BACKUP commands even after a failed backup is welcome (do you have more real-world scenaria than the one with DBMS stop/start?)
A PR implementing the new syntax for PRE/POST_RECOVERY only has been merged. Is it acceptable to add only that and avoid any additions to PRE/POST_BACKUP ? Note that PR 2735 does not preserve the original semantics of exit task handling in PRE/POST_BACKUP_SCRIPT for PRE/POST_BACKUP_COMMANDS: POST_BACKUP_SCRIPT is executed on error only if PRE_BACKUP_SCRIPT is set, as noted in https://github.com/rear/rear/pull/2735#issuecomment-1145006984, while no such logic exists for POST_BACKUP_COMMANDS.
Hi Pavel, I'm sorry I totally forgot this. Please do what you consider best here.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (rear bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:7654