On 06/05/2015 01:36 PM, dweimer wrote: ... > which is true, I don't know what I am doing, yes the point of the > #!/usr/bin/env perl is to then find the first perl in the users path, > and the above probably should have been stated as a quick work around. > The true fix would be to determine why /usr/local/bin isn't found in the > path in the user context in which it is ran under the job and correct that.
As I posted before, a better fix would be to edit RunBeforeJob in BackupCatalog jobdef to call the appropriate db dumper directly. Here's why: - The file you're editing is a config file so your changes are preserved on software update. Your changes to the script aren't. - What the script does is parse the above config file and figure out the database engine type and connection parameters so it can call the appropriate db dumper utility. There is a number of problems with it: included config files that don't get parsed, /var/spool/bacula is hardcoded instead of read from the config file, there's probably more (I only looked at it very briefly). You could do all of that better by just looking at that config file of yours. - As you found out, for some unclear reason your backups stopped working after a seemingly unrelated software update. If an update breaks bacula, you want to find out when updating/restarting *bacula*, which is what'd happen if bacula failed to parse its own config file. - On top of that there's the #!/usr/bin/env that many consider a classic example of "now you have two problems". -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
