From the viewpoint of the process, there's not much difference. A SIGKILL
terminates the process immediately and without asking questions (if it can).
The surrounding environment is a different matter, though. Consider a disk write. A process calls write()
, and if that's successful, the buck is passed to the operating system. Killing the process now doesn't cause loss of the written data, it's the job of the OS to guarantee that. But the data is still not safely on permanent storage, as the OS might not have sent it to the disk, or the disk might not have written it to permanent storage.
Pulling the power from the whole system would wipe out any in-memory caches of the OS (which is why you'd usually have an UPS to ensure clean shutdown), as well as any volatile cache on the storage device (which is why the pricey stuff have batteries of their own).
Forcibly terminating a VM would be somewhere in between. If the VM supervisor dies, what ever is inside it is lost. But anything already sent to the host system should be safe.
How much the difference matters, depends on your scenario (and risk assessment). If you're testing a low-level database that's supposed to be resilient to hardware failures, then testing by actually pulling the plug may be quite important. But if you're testing a higher-level application that uses a database that deals with stuff like that, then you probably don't need to test all that yourself.
While I would expect all serious database applications to at least try to deal with power failures sensibly, SQLite in particular has a number of articles describing what they do to that end, see e.g. https://www.sqlite.org/atomiccommit.html and https://www.sqlite.org/howtocorrupt.html .
Note: I said "if it can" about SIGKILL. Depending on the OS, there might be scenarios where SIGKILL can't kill a process. E.g. on Linux, processes in the "uninterruptible sleep" state (D) don't die before whatever they're waiting for resolves. See e.g.: What does a program do when it's sent SIGKILL signal? and How to kill a task that cannot be killed (uninterruptable?)