On Thursday 22 September 2005 16:06, Stephan Ebelt wrote: > Martin Simmons wrote: > > Stephan> that means it always terminates with '*** Backup Error ***' > > when you Stephan> exit with e.g. 5? > > > > Correct -- a non-zero exit code from the ClientRunBeforeJob always > > results in '*** Backup Error ***'. Also, I always get 'Backup OK' > > regardless of the exit code from ClientRunAfterJob. > > exactly the same here. > > [...] > > > Stephan> Or do you mean that the return code of ClientRunBeforeJob is > > send to the Stephan> director before the ClientRunAfterJob is executed? > > That would make sense. > > > > No, I meant the count of "Non-fatal FD errors" (which changes 'Backup OK' > > to 'Backup OK -- with warnings' when > 0). You said that this count is 1 > > when your ClientRunAfterJob script returns certain error codes, but I > > don't see how that can happen. > > ah, I see. > > I tried again: one job with ClientRunBeforeJob returning 0 and > ClientRunAfterJob returning 5. The result was 'Backup OK'. So there must > have been something else in the previous try. That's my fault then. > Here's the output: > > 22-Sep 15:11 dd-lx-backup.dd.net-linx: Start Backup JobId 1047, > Job=DD31.2005-09-22_15.11.28 > 22-Sep 15:11 dd-lx-backup.dd.net-linx: Volume "disk4-0009" previously > written, moving to end of data. > 22-Sep 15:11 dd-lx-oracle3.dd.net-linx: DD31.2005-09-22_15.11.28 Fatal > error: ClientRunAfterJob returned non-zero status=268435461. ERR=Child > exited with code 5 > 22-Sep 15:11 dd-lx-backup.dd.net-linx: Bacula 1.36.3 (22Apr05): > 22-Sep-2005 15:11:31 > JobId: 1047 > Job: DD31.2005-09-22_15.11.28 > Backup Level: Incremental, since=2005-09-21 10:53:10 > Client: dd-lx-oracle3 > FileSet: "Data-UNIX-Oracle" 2005-08-05 19:00:01 > Pool: "disk4" > Storage: "disk4" > Start time: 22-Sep-2005 15:11:29 > End time: 22-Sep-2005 15:11:31 > FD Files Written: 0 > SD Files Written: 0 > FD Bytes Written: 0 > SD Bytes Written: 0 > Rate: 0.0 KB/s > Software Compression: None > Volume name(s): disk4-0009 > Volume Session Id: 54 > Volume Session Time: 1127203794 > Last Volume Bytes: 39,178,621,354 > Non-fatal FD errors: 0 > SD Errors: 0 > FD termination status: OK > SD termination status: OK > Termination: Backup OK > > [...] > > > Stephan> hmmm, from how I understood the manual it should work exactly > > like this? Stephan> It says: > > > > Stephan> Run After Job = <command> > > Stephan> The specified command is run as an external program after > > the Stephan> current job terminates. This directive is not required. > > The command Stephan> string must be a valid program name or name of > > a shell script. If Stephan> the exit code of the program run is > > non-zero, the current Bacula job Stephan> will terminate in error. > > Before submitting the specified command to Stephan> the operating > > system, Bacula performs character substitution as Stephan> described > > above for the Run Before Job directive. > > > > Stephan> An example of the use of this command is given in the > > Tips Chapter Stephan> of this manual. As of version 1.30, Bacula > > checks the exit status of Stephan> the RunAfter program. If it is > > non-zero, the job will be terminated Stephan> in error. > > > > Stephan> [...] > > > > Stephan> Client Run After Job = <command> > > Stephan> This command is the same as Run After Job except that it > > is run on Stephan> the client machine. Note, please see the notes > > above in Client Run Stephan> Before Job concerning Windows clients. > > > > I've never seen it behave like that, so I suspect the doc is wrong. > > hmm, before we correct the doc I guess it would be worth thinking about > modifing the code since the doc appears to make a lot of sense? To me in > that situation at least. > > Should I log this as a bug?
I think that this is a "bug" in the documentation. I've taken note to look at the code, but from memory, the RunAfterJob (as well as ClientRun...) is run after the job, hence the job has already terminated normally and marked as such in the database. I'm not sure if this was the original behavior or if I modified it to work that way, but it seems to me to be a shame to fail the whole backup when it actually worked. Perhaps in the near future with Python scripting you will be able to modify this behavior if you want (not yet possible). Note: on Windows (may not apply here), I have been unable to successfully get the script termination code, so what is reported as the code may or may not be correct. In addition as noted in the doc, Windows itself limits the codes (Bacula uses 250+ if I remember right). In fact, if you chose the wrong code on Windows, the FD will loop forever (see the doc). On Windows, it is probably better to use 0 or 1 only. > > Another test would be to try the same with RunAfterJob. And see what > happens then. I'll do that later. > > Stephan > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
