Re:Kill Me Softly – Kill processes in a reliable manner
by alanfranzoni on Wednesday December 17, 2014 @03:07AM
(#8761537)
I'm not speaking about the software I write - for that software, I strive for a way to ALWAYS recover, even from and hard crash, without getting mad. But even there the automatic recovery sometimes is not completely immediate (it may take a bit of time at startup), so a direct SIGKILL is still something I don't strive for.
But when I'm on my workstation, I need to kill other software as well. I have an UPS on my workstation, and the UPS is very close to the workstation, so the tripping is unlinkely :-)
And when hard crashes happen, sometimes I find some software in an incosinstent state, and I need to cleanup something manually.
Or maybe a remote endpoint for any software would like to be notified of me shutting down, something that's usually done with a clean exit, not with a SIGKILL. Or temporary files would be cleaned up immediately, rather than on a cron-based janitoring job.
I have implemented practical running systems that work like that so it is practical not just academic papers.
> But the real world doesn't always work this way.
Sure, sometimes you don't have choice. You get a 3rd party library/service/db that will shit the bed if something pulls the plug on the machine. You can try to identify those parts and eliminate them or mitigate it as much as possible. But sometimes you can't. Then try to characterise their behavior. Maybe have some external cleanup logic if you care to ensure data doesn't get corrupted. And live with it.
> Not every software in the world has the amount of testing for hard kills as an ACID compliant RDBMS - I'd say all the contrary.
Well but it is something to strive for. If you write the software it benefits to understand what happens to the data. Knowing a bit about file syncing, what kernel does with dirty pages, how/if/when to use O_DIRECT, using append-only modes, a write-ahead log. Think about using checksums in your persistent data, take advantage of atomic file system operations (renames), etc.
Well I certainly saw the benefit and the return from running a better, well tested, well designed service that operates that way.
> Let processes cleanup after themselves,
Think about that statement for a bit. How do you guarnatee processes "cleanup up after themselves". Say a junior tech trips over the power cord of the server, how does the process "clean up after itself"?