Steps to Reproduce (on Debian, installing via apt-get koha-common): (1) Use koha-run-backups on an older Koha version (I used 3.10 which has been updated from an even older installation). (2) koha-restore data and configuration from step (1) into a Koha 3.12 installation. (3) Run /usr/sbin/koha-dump. Actual Result: It says "Dumping Koha site [...]:". Nothing else happens. Expected Result: Two dump files. Workaround: Remove the "set -e" line in /usr/sbin/koha-dump Additional Information: The older configuration doesn't have a config/backupdir entry. backupdir="$( xmlstarlet sel -t -v 'yazgfs/config/backupdir' $kohaconfig )" therefore returns 1 and exits koha-dump.
Did you specify an instance to dump when you ran koha-dump? The correct syntax is: koha-dump instancename Just making sure. :)
The best solution would be a fallback for the backup path.
(In reply to Robin Sheat from comment #2) > The best solution would be a fallback for the backup path. The fallback is already sort of implemented. It just doesn't work because xmlstarlet returns non-zero which kills koha-dump immediately due to its "set -e" setting.
(In reply to Bert Burgemeister from comment #3) > The fallback is already sort of implemented. It just doesn't work > because xmlstarlet returns non-zero which kills koha-dump immediately > due to its "set -e" setting. It'd be better to fix that case with some error handling (or even just '|| true' to hide it if appropriate) than turn off the error aborting script-wide, as that may cause it to try to plow on rather than die if something else goes wrong.
Created attachment 23010 [details] [review] Bug 10735 - prevent script aborting if backupdir undefined Older versions of Koha didn't have <backupdir>...</backupdir> defined in koha-conf.xml. The koha-dump script is aware of this, and checks to see if it's there. However, if it's not, xmlstarlet returns a non-0 error code which causes the script to abort due to running under set -e. Test plan: * Remove backupdir from koha-conf.xml * Run koha-dump, notice that it doesn't do backups * Apply patch * Run koha-dump again, notice that it does do backups
Patch applied against master, but I'd expect it to backport cleanly.
Created attachment 23700 [details] [review] Bug 10735 - prevent script aborting if backupdir undefined Older versions of Koha didn't have <backupdir>...</backupdir> defined in koha-conf.xml. The koha-dump script is aware of this, and checks to see if it's there. However, if it's not, xmlstarlet returns a non-0 error code which causes the script to abort due to running under set -e. Test plan: * Remove backupdir from koha-conf.xml * Run koha-dump, notice that it doesn't do backups * Apply patch * Run koha-dump again, notice that it does do backups Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> The fallback method works as described. It might be made more robust like checking for dir existence (thinking of older instances upgrades). But it certaintly belongs to another bug report.
Created attachment 23784 [details] [review] Bug 10735 - prevent script aborting if backupdir undefined Older versions of Koha didn't have <backupdir>...</backupdir> defined in koha-conf.xml. The koha-dump script is aware of this, and checks to see if it's there. However, if it's not, xmlstarlet returns a non-0 error code which causes the script to abort due to running under set -e. Test plan: * Remove backupdir from koha-conf.xml * Run koha-dump, notice that it doesn't do backups * Apply patch * Run koha-dump again, notice that it does do backups Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> The fallback method works as described. It might be made more robust like checking for dir existence (thinking of older instances upgrades). But it certaintly belongs to another bug report. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> As Tomas said, it would be better to alert the user if the backupdir tag does not exist (or contains a nonexistent directory) in the config file.
The patch is for master and can be backported to stable branches.
Pushed to master. Thanks, Robin!
Patch pushed to 3.14.x, will be in 3.14.2.
This patch has been pushed to 3.12.x, will be in 3.12.9. Thanks Robin!