Hello Arno, Well, your output pointed out a problem where one "insanity" check flag was not being correctly set, so in your case of many conflicting demands for resources, it prematurely failed your job thinking there was no suitable drive. I have fixed this (I think) by moving the code a bit, so if all goes well, that problem should be eliminated.
If there are additional problems (I hope not), we can work on them one at a time. I'll be releasing 1.38.3 today. Normally I would have preferred to release the code from 26Dec05 that has been running since then in production here, but the change I made to (hopefully) correct your poblem seems simple enough that my regression testing should be sufficient. To minimize possible problems I have not moved the locking code as previously discussed but will do it in version 1.38.4 Yes, I am getting a bit tired of working on "bug" fixes and would like to get on with new development, but fear it will be a few more weeks because I need to fix the watchdog seg fault, and add additional debug code to the reservation system so that users can more easily see why a job is waiting. To answer your previous email. "Ich möchte und werde München besichtigen, aber das Problem soll feststellen, wann es möglich ist." (translation: I would like to and will visit Munich, but the problem is when it will be possible". On the 21st of January, I leave for 2 months of "vacation" in Southern France. This should be quite an experience to be away from home for 2 months. I will, of course, be taking my portable computer, and will be working on 1.39, but I cannot be 100% guaranteed of good connectivity. If all goes well, I will find some way to get a high speed connection to the Internet, in which case, most things will continue as normal. In the minimum, I will have daily GPRS connection, and probably high speed once a week. I think the biggest problem for me will be not having my computer books handy ... On Wednesday 04 January 2006 22:51, Arno Lehmann wrote: > hi, > > On 1/4/2006 9:42 PM, Kern Sibbald wrote: > > On Wednesday 04 January 2006 21:15, Arno Lehmann wrote: > >>On 1/4/2006 8:44 PM, Kern Sibbald wrote: > > ... > > > Thanks. Got it. > > ... > > > Hmmm. Unfortunately the "trick" I mentioned is not true. I was looking > > at your output more in detail when I realized that the locking is one > > level down from where I thought it was, which means that all the jobs are > > trying to run through the same algorithm at the same time. They are > > locked from any direct conflict, but after a bit of thought I think it > > would be better for a single job to try all possibilities before letting > > another job try -- if nothing else, that will reduce the complexity when > > trying to figure out what went wrong. > > Well, "reducing complexity" almost always is the right thing to do :-) > > > After looking over your full output in detail, I will probably release > > version 1.38.3 tomorrow because it seems to be better than any of the > > previous versions, then I'm going to move the locking code up one level > > of subroutine to the main loop and add a bit more debug code that could > > be helpful in analyzing your problem. > > Good, then I think I can go on testing that. Tomorrow... Thursday. New > version starts running on Friday or Saturday, that gives me at least two > days of simple operation to find configuration issues or other bugs > before my stressing set up starts. Sounds good. > > > Assuming looking at your full output doesn't give me the info needed to > > resolve the problem, once I test the new locking code and the new debug > > output (don't expect any problems) I'll make it available so we can get > > to the bottom of this problem ... > > I'd really really like to get this fixed... after all, there should be > more, new, exiting bugs to hunt ;-) (And I guess you'd like to get the > known bugs fixed so you can implement new... no! features!!) > > Arno -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users