Hi, Again, thanks for the interest in my problem. I was certainly not expecting a patch for this old version of Bacula. This system will get a Bacula version update when the update to Debian occurs, according to the local policy governing this system. I actually did not assume that there was a Bacula bug here, though I could argue that there is a bug of not reporting more detailed error information from Postgresql -- I am sure that Postgresql provides more detailed information than 'Update failed'.
It's too late to run the SQL command you suggested. The dbcheck run mentioned in my original post would have deleted it if it was present. I have not seen this error recur. If it does, I will look into the tracing you mention. While I have no direct experience with Bacula trace files, it does not seem that it would be impossible to use tools to find a database error, and then perhaps see the error returned by Postgres. I could be wrong about that. I might also be mistaken in my thinking that knowing why the update failed would be helpful. Best regards, Ken -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Thursday, December 11, 2025 2:13 PM To: [email protected] Subject: Re: [Bacula-users] Troubleshoot bdb.h fatal error? Hi Ken, Am 11.12.2025 um 20:26 schrieb [email protected]: > Rob, Arno, > > Thank you for taking an interest in my problem. You're welcome! Looks like the simple, obvious things do not help us here. So... > Answers to questions, as best as I can provide: > >> from Rob: >> You mentioned that the last two admin jobs failed. Was that a typo? If not, >> what errors did the last job (unmount, eject) give? > > The errors for jobid 27943 look very much like the errors for 27941. > > 08-Dec 14:21 linux2-dir JobId 27943: Fatal error: bdb.h:140 Update failed: > affected_rows=0 for UPDATE Job SET JobStatus='R',Level=' > ',StartTime='2025-12-08 > 14:21:57',ClientId=1,JobTDate=1765225317,PoolId=0,FileSetId=0 WHERE > JobId=27943 > 08-Dec 14:21 linux2-dir JobId 27943: Fatal error: bdb.h:140 Update failed: > affected_rows=0 for UPDATE Job SET JobStatus='f',Level=' > ',StartTime='2025-12-08 > 14:21:57',ClientId=1,JobTDate=1765225317,PoolId=0,FileSetId=0 WHERE > JobId=27943 We#ll need to find out what failed here. There is a simple possibility for the catalog update to fail, that is when the row its supposed to update does not exist. In bconsole, do sql select * from job where jobid=27943; and see if it finds that row. If it doesn't, I'm wondering why the fact that such a job could not be created was not reported -- it should have been. > 08-Dec 14:21 linux2-dir JobId 27943: Warning: Error updating job record. > bdb.h:140 Update failed: affected_rows=0 for UPDATE Job SET > JobStatus='f',EndTime='2025-12-08 > 14:21:57',ClientId=1,JobBytes=0,ReadBytes=0,JobFiles=0,JobErrors=1,VolSessionId=0,VolSessionTime=0,PoolId=0,FileSetId=0,JobTDate=1765225317,RealEndTime='2025-12-08 > 14:21:57',PriorJobId=0,HasBase=0,PurgedFiles=0 WHERE JobId=27943 > 08-Dec 14:21 linux2-dir JobId 27943: Warning: Error getting Job record for > Job report: ERR=sql_get.c:303 No Job found for JobId 27943 We can probably guess the result of above exercise, but let's not guess :-) > 08-Dec 14:21 linux2-dir JobId 27943: Error: Bacula 9.6.7 (10Dec20): > 08-Dec-2025 14:21:57 So we would have to investigate if the DIR for some reason "forgot" to create a job record when the job was started (I have never experienced such a thing, but that doesn't prove anything), if it didn't log it for some reason, if you just missed the error message (that would be convenient in this case :-) or if something deleted it in between successful job creation and the first update. Debugging, as a user, something that did *not* happen is a bit of a challenge, but we can probably achieve something if you can reproduce the problem. However, we'll probably not be able to convince Eric and team to fix issues in version 9 anymore. Thus -- would you be able to upgrade to a recent version, preferrbla the most recent one? I would recommend using the packages you can subscribe to at https://www.bacula.org/bacula-binary-package-download/ but, if that's not a choice you would consider, building from source is also an option. Proper packaging is above my pay grade, though :-) The alternative to enable tracing, debug, reproduce and eventually carefully read a few million lines of traces files will probably get us somewhere, but will not actually solve anything... Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
