4 ms·

Your point of view is correct, from a purely theoretical point of view. But the real world doesn't always work this way. The recovery process after a SIGKILL m

Your point of view is correct, from a purely theoretical point of view. But the real world doesn't always work this way. The recovery process after a SIGKILL may require manual intervention, or may leave some data in an inconsistent state. 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. So, I don't want to trigger bugs and lose time in complicate recoveries if I am absolutely not forced to do it. Let processes cleanup after themselves, and hit them hard only when and if needed.

dap 12y ago
I hear what you're saying, but the flip side is that all that software also won't work when you lose power or the system panics. I've found it much easier to just always use SIGKILL. That way, you're testing the recovery code all the time, especially during development when you restart, upgrade, or after a crash. You fix the bugs, and you have high confidence because you're exercising this path all the time.
rdtsc 12y ago
> from a purely theoretical point of view. But the real world doesn't always work this way. 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"?
- alanfranzoni 12y ago
  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.

dap 12y ago

I hear what you're saying, but the flip side is that all that software also won't work when you lose power or the system panics. I've found it much easier to just always use SIGKILL. That way, you're testing the recovery code all the time, especially during development when you restart, upgrade, or after a crash. You fix the bugs, and you have high confidence because you're exercising this path all the time.

rdtsc 12y ago

> from a purely theoretical point of view. But the real world doesn't always work this way. 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"?

alanfranzoni 12y ago
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.