Hi Antoine, > Bacula seems to be configured to unconditionnally send a backtrace > when it crashes. The TRACEBACK define seems to be unconditionnally set > in `version.h`, regardless of any configuration flag. (Same with > DEBUG, by the way.) > > Production software should require us to ship with debugging > symbols. If it fails and crashes and burn, it should send a proper, > actionable, error message instead of going crazy.
the crash you see happens after clear error messages are given, see the transcript at the end. Even if not run in the foreground, clear error messages are sent to syslog. It's neither required to have debugging symbols installed nor to have gdb installed. The report will just be less useful for debugging purposes. Usually an email is generated when a crash happens, whatever the exact content is, it does alert the admin to the fact that there is a problem. Could you explain how you would want this improved? Regards, Carsten # /usr/sbin/bacula-fd -f -c /etc/bacula/bacula-fd.conf cixi: Warning: Cannot bind port 22: ERR=Address already in use: Retrying ... cixi: ABORTING due to ERROR in bnet_server.c:132 Cannot bind port 22: ERR=Address already in use. 26-Mar 19:59 cixi: ABORTING due to ERROR in bnet_server.c:132 Cannot bind port 22: ERR=Address already in use. Bacula interrupted by signal 11: Segmentation violation Kaboom! bacula-fd, cixi got signal 11 - Segmentation violation at 26-Mar-2020 19:59:48. Attempting traceback. Kaboom! exepath=/usr/sbin/ Calling: /usr/sbin/btraceback /usr/sbin/bacula-fd 4576 /var/lib/bacula It looks like the traceback worked... LockDump: /var/lib/bacula/bacula.4576.traceback cixi: lockmgr.c:1221-0 lockmgr disabled free(): invalid next size (fast)