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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users