I just don’t think that you can ever cause this particular architecture to be sufficiently reliable.

If the Titanic is going down, then you might have a chance to snap off a distress-call ... but whoever records that urgent message in a database needs to be in the warm, dry, radio-room of the Carpathia.

Obviously the most reliable approach, if you can manage it, would be to snag that TERM signal, so that your application can respond to it but do so under its own terms and in a manner of its own choosing.   The signal is treated as an unconditional command given by higher powers, “kill yourself as soon as possible... have a nice day.”   But the application does so in such a way that it can reliably and safely record the fact in a database.   It abandons what it is doing and accomplishes a known-good ROLLBACK.   It logs the abnormal-termination event and cleanly commits that transaction before cleanly closing the database handle before it finally, graciously, “gives up the gho”   ;-)

If you are working in an environment such as Windows, or in certain Unix/Linux environments, you might have at your disposal an “event logging” facility which can serve as an adjunct or as an alternative to attempting to write to a production database under such circumstances.   Just get the distress-call off to the event-logger, who is always “warm and dry.” At system-shutdown time, it is expressly set aside to “be there until (almost) the bitter end,” for this very purpose.