[PATCH] Log message before aborting

[Ondrej Zajicek]

On Wed, Jan 11, 2023 at 11:51:12AM -0800, Michael Crute wrote:
> On Wed, Jan 11, 2023, at 08:36, Ondrej Zajicek wrote:
> > 1) vlog() (which is internally caled from bug()) is not safe to call from
> > a signal handler, as it internally takes a mutex, if the signal is received
> > when the interrupted thread is already in mutex, it will deadlock.
> >
> > 2) This alarm is here to ensure that BIRD does not hang, if there is some
> > issue withing logging (e.g. deadlock or long-term blocking on write), we
> > could hang on the logging, circumventing the watchdog.
> >
> > 3) bug() has slightly different meaning, so it is not really matching
> > here, but that is easily fixed by using log() and abort() separately.
> >
> > These issues could be fixed, but more intricate approach has to be used.
> 
> Thanks Ondrej. I did not realize that vlog was unsafe in this context. It looks like the debug function is closer to a correct solution except that on error it will call bug and also fputs is not async safe.
> 
> My goal is to present some log message immediately prior to abort to alert the user that this crash was on purpose. I think this would have helped our Alpine user find their configuration error faster rather than wasting time debugging the bird binary itself.
> 
> Is this proposed log function a valid solution?:
> 
> void
> watchdog_debug(const char *msg)
> {
>   if (dbgf)
>     {
>       write(dbgf, msg, strlen(msg));
>       abort();
>     }
> }

That would work (with some minor modifications - abort() should be out of
condition, dbgf is FILE *, not fd, fileno() is not async-safe, so we would
need keep dbg_fd).

The disadantage is it would not write to log file, but only to debug
output (enabled with -d / -D option). If that is acceptable to you,
i would apply necessary changes.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."