Guarantee code execution even on process kill

Question

I need to execute a portion of code (the state save) on the process stopping - by itself, by user, by task manager, etc.

Is it possible?

try {} finally {}, AppDomain.ProcessExit, IDisposable, destructor,.. what next to try?

Answer 1

As others have pointed out, there is no way you can execute any code in your application when it is being Killed by Operating System or User. That is why its called Killing.

If saving the state is an important part of your application, you should take an approach similar to a database system. Implementing transaction log, creating checkpoints, etc. That is the closest you can get.

In that case, when your application revives (is re-run after being killed), it can check these transaction logs for any pending updates or last state changes.

Other than that, it really depends on what you want to do. And also why you came up with this idea? Can we get more details? May be someone here has better alternative.

Answer 2

The whole point of a process being killed ungracefully is that it just stops what it is doing. I can't really see a way around that.

Answer 3

You need to think about why your program is exiting. If it is because of an error, then you can use try/catch. In unix terms, what goes on when the process manager halts a process is a kill (i.e. sends a SIGKILL signal) which doesnt allow the program to do anything before the process is exited. What many viruses do is have two processes (possibly with shared memory to avoid constant data synchronization), each monitoring the state of the other and when one goes down, the other respawns it. Perhaps a second process could monitor and save the state in a similar way for your case. The other kind of signal though is a SIGTERM. This signal is sent when you tell your computer to restart but there are processes running. The kernel allows the programs to try and quit on their own, but eventually will ask the user if it is okay to kill the program. If you want to handle SIGTERM lookup handling signals. Ultimately the only solution that I know of to the SIGKILL is the two process solution.

Answer 4

I was looking around for a somewhat different reason than what is posted, but I came up with a pretty good solution for myself and it might useful to state here:

NOTE: To those that know what it is, this is essentially the 'Heartbeat' design pattern.

1) In addition to the code running that will 'die' (ie be killed), add code to this project such that it spawns a thread (or possibly another method?) upon initialization, and all the thread does is run a never-ending while loop (but make sure it sleeps at least a few seconds or even 1 minute between iterations) and in the while loop, record an indicator to indicate your app is 'alive' (ie the 'heartbeat'). I personally recommend setting a value in either the DB, or perhaps a file, that is the current timestamp (ie DateTime.Now)

2) Now that you are recording the 'heartbeat', create another app (ie another process) that does nothing but reads the heartbeat value (ie the current timestamp) and does this in a never-ending while loop. Once its determined that the heartbeat value is 'bad' (ie maybe if, say, HeartBeatTimestamp + 5 min < DateTime.Now), you can now run your code that you desire to run 'once the process is killed'

Hope this helps :) Feel free to research the 'Heartbeat' design pattern from other resources to if you want to know more!

Cheers,

Jeff