Hi Pierre, sorry for the long delay before getting back to you.
Pierre Bernhardt <pie...@starcumulus.owl.de> writes: > I tried to get a backtrace allready, but it was not possible. However I don't > understood why backtrace was not created :-( > > The only content what i got from baculas home dir ant e.g. the > backup-sd.3282.bactrace > file is: > Attempt to dump current JCRs. njcrs=1 > threadid=0x7feac0c2b700 JobId=22108 JobStatus=C jcr=0xadd128 > name=file_home.2014-10-21_23.50.01_09 > threadid=0x7feac0c2b700 killable=1 JobId=22108 JobStatus=C jcr=0xadd128 > name=file_home.2014-10-21_23.50.01_09 > use_count=1 > JobType=B JobLevel=I > sched_time=22-Oct-2014 00:13 start_time=01-Jan-1970 01:00 > end_time=01-Jan-1970 01:00 wait_time=01-Jan-1970 01:00 > db=(nil) db_batch=(nil) batch_started=0 > Attempt to dump plugins. Hook count=0 > > The good it's fully reproducible. I get many output from console if I start > bacula-sd by using /etc/init.d/bacula-sd start maybe with higher logging > level. > > All my communication is encrypted and signed by TLS. All hostsystems have > different > private keys and own signed certs to prevent also from mitm attacks. > Maybe the occurs only by activated TLS communication. If you didn't test it > yet > please try to activate TLS. I also have a setup with encryption/authentication with TLS, yet I have never seen the storage daemon crash when an fd is unreachable. And it's every day that some FDs are unreachable in my installations. The only difference is that you are encrypting the data to your storage, but I would be surprised that this would be related to the crashes. Would you be able to check if the problem persists with the current version 7.4.3 (which is also in jessie-backports)? I've since learned that it's not possible to get a backtrace when the daemons are started with "-u bacula". This will be addressed in one of the next versions to enter unstable. Maybe we'll find the source of the problem then. - Carsten
