[pkg-bacula-devel] Bug#954971: should not try to send a traceback in production

Antoine Beaupré anarcat at debian.org
Fri Mar 27 13:19:38 GMT 2020


On 2020-03-27 09:21:23, Carsten Leonhardt wrote:
> Antoine Beaupré <anarcat at debian.org> writes:
>
>>> Could you explain how you would want this improved?
>>
>> I would prefer that no email is sent at all, or have that
>> configurable. I would prefer, in fact, that TRACEBACK is disabled at
>> compile time, unless the debugging symbols are shipped.
>
> At compile time we can't know if debugging symbols will be available
> later, as they are installable anytime from the -dbgsym packages.
>
> What would be possible is to adapt the script "btraceback" to not send
> the email if so requested by some mechanism. I don't think embedding a
> parser for the configuration file in the script would make sense, it
> would need to be something simple like checking the existence of a file
> "/etc/bacula/no_tracebacks_please".

That would work. It could also check if the debugging symbols are
available, or handle more gracefully the absence of gdb.

> I'm curious though to understand your motivation for not wanting the
> emails, would you care to explain?

We have two monitoring systems for the backups:

 * on the backup server, where we check the timestamp
 * on the client itself, where systemd checks that the system is running

I don't need a *third* place to tell me when trouble happens. In
particular, this is happening during a server migration where the imaged
copy of the server is crashing because DNS is not resolving to the new
server's IP address (and understandably so). There's a workaround: fix
/etc/hosts, but we don't usually insert IPv6 addresses in there.

I especially don't need an unhelpful message like "gdb: not found". For
new people in the team, that message is extremely confusing, and will
just send them spiraling down a quite difficult debugging spree. In my
case, I had to inspect the C source code of bacula to figure out what,
exactly, was going on. The email did tell me there was a problem, but it
didn't tell me what it was and it didn't tell me how to find what it
was.

If an email will be sent, it should at least feature a proper error
message. Otherwise it should not send an email at all.

(I would also argue that Bacula shouldn't *segfault* if it can't bind to
IPv6 on a dual-stack host, but that's just me...)

A.

PS: I might have mentioned this before, but the gory detail of those
diagnostics are available in:

https://trac.torproject.org/projects/tor/ticket/33732

-- 
During times of universal deceit, telling the truth becomes a
revolutionary act.       - Georges Orwell



More information about the pkg-bacula-devel mailing list