Fatal signals should be logged

[Eric Siegerman]

If bzr is killed by a signal, e.g. SIGTERM, it should write a .bzr.log line indicating what happened.

This seems related to https://bugs.launchpad.net/bzr/+bug/41476, but doesn't seem to be precisely a duplicate.

ISSUE: Which signals should be treated in this manner? From a debugging perspective, the more the better, of those signals that aren't already caught for other reasons; but the above-mentioned bug discusses some signals that should *not* be trapped for its purposes, and some of that reasoning might apply here as well.

[Martin Pool (mbp)]

On 7 January 2011 15:31, Eric Siegerman <email address hidden> wrote:
> Public bug reported:
>
> If bzr is killed by a signal, e.g. SIGTERM, it should write a .bzr.log
> line indicating what happened.

Any particular reason why?

--
Martin

[Eric Siegerman (eric97)]

I was looking into the "Multiple program crashes under Windows 7" thread on the Bazaar mailing list, from 7-Jan-2011. Figuring out the user's .bzr.log was made difficult by two things. The one that's relevant to this bug is that "bzr explorer" processes (at least I think it was them) simply vanished without any indication as to why. I *think* this is because the user hit "end program" on a Windows-7 "program has crashed" dialog, but don't know. (That is, the user has said that's what he did, but I can only guess that it was "bzr explorer" processes, and not "bzr something_else"s, that he was terminating.)

Thus, to help this user, my proximate need was for there to be a trace when Windows 7 throws up a "program has crashed" dialog and the user hits "end program". Admittedly, I'm speculating that the "end program" user action ultimately gets mapped to a signal (SIGTERM perhaps?) that's visible to Python code, and thus that logging bzr aborts due to the signal in question would make it easier to see what's going on for this user.

But ISTM that even if my "end-program maps to signal" guess is wrong, logging aborts due to signals would help folks to analyze other similar sorts of problems. That's why I wrote the suggestion as I did. If it turns out that implementing this *doesn't* cause "end program" events to be logged, that can be addressed separately, if "end program"'s implementation allows it.

(FYI: the other difficulty I had was that mutter() output doesn't contain the PID, which made it a challenge, and a bit of a guessing game, to unscramble the messages from "bzr explorer" and its various subprocesses; I'm working on a patch to fix that one).