[pkg-bacula-devel] Bug#486131: bacula-sd crashes with unreachable FDs

[Carsten Leonhardt]

Hi Pierre,

sorry for the long delay before getting back to you.

Pierre Bernhardt <pierre at 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