4 ms·

As if often the case with stackoverflow answers, all of them are wrong in different ways. You should only kill -9 when every other signal the program is likely

• TillE 12y ago
  You can't really corrupt a database that easily, can you? That's half the point of using a database, so you have transactions, etc.
  • btmorex 12y ago
    not corrupt != everything is peachy At the very least, you need to be prepared for a possibly very long replay of logs. Also, a huge number of people run databases in a configuration that doesn't make those guarantees. For example, many people will run mysql (esp. less performant slaves) with innodb_flush_log_at_trx_commit = 0 for performance with the understanding that a failure might require manual fixes.
    • seunosewa 12y ago
      A failure with that parameter will only cause transactions committed in the last second to be lost. The DB won't require manual fixes.
      • spudlyo 12y ago
        The DB won't require manual fixes. Losing a transaction that was committed upstream can lead to a bunch of manual fixes in replicated database clusters. What happens if rows inserted in that lost transaction are eventually updated? Replication breaks, you get paged, and now you're faced with either manually fixing the DB consistency error or by rebuilding the whole slave. Woe be unto you if this host is a replication hub with a bunch of slaves hanging off it.
  • servowire 12y ago
    I don't remember the exact details, but I once had a DB admin flabbergasted because there was a non-numeric character in a field/row that was numeric. The DB engine crashed upon starting and could not clean it up. I think it was Oracle. If I remember correctly we had to get the vendor involved This happened after an unclean shutdown (power failure). The disk were RAID, but the cache battery was dead so there was some corrupt data written to the disk on block level. THis could happen too on a kill -9.
  • maaaats 12y ago
    I've never corrupted the DB, but I have ended up with inconsistencies because I needed to do several related queries in a row. Because I didn't send them as a single transaction from my application some of them were run, some not. Edit: Especially when you have multiple systems that should be consistent. Deleting a user from the DB, but being killed before it can be removed from our auth system, for instance.
    • spullara 12y ago
      The typical way of ensuring consistency in cases where the systems are unable to participate in a transaction would be to use a durable queue between the systems that can participate. So, in your Edit example, you would delete the user from the DB and add it the user to a queue in the same database to be deleted. Another process would then pull from that queue and attempt to delete from the auth system and only acknowledges the message once it is successful. You will still temporarily be in an inconsistent state but ultimately the operation will complete. This design only works for idempotent work.
• stingraycharles 12y ago
  As a useful variant of this: I have grown accustomed to killing processes that hang with kill -11 (SIGSEGV). This is essentially the same as -9, with the exception that it creates a coredump. Saves a lot of hassle with manually attaching GDB.
  • btmorex 12y ago
    Yup, there are risks too though with that approach. You should be sure that ulimit for core size is large enough (not default almost always). Also, a core dump can take a very long time if your programs address space is large. It might involve writing tens of gigabytes to disk. So not only do you need the file system space, but you also need to be prepared to wait tens of minutes while your program is dumping core.
    • stingraycharles 12y ago
      While what you say is true, this is not really a problem in practice; most of the time, the process doesn't have the amount of memory allocated to be a serious problem, and the coredump file is written in a smart way [1]: usually, the address space has many 'gaps': instead of writing these all as \0 characters to disk, it uses more elaborate storage techniques. The end result is that you can have a coredump file which is reported to have a size of 1GB, while only having 100MB written on disk. [1] https://en.wikipedia.org/wiki/Core_dump#Format https://en.wikipedia.org/wiki/Core_dump#Format
  • dfox 12y ago
    It's probably better to use SIGABRT (-6) for that, as it also dumps core and is less likely to be handled by the process (there are valid reasons to handle SIGSEGV and continue in execution)
    • voltagex_ 12y ago
      I never thought of handling SIGSEGV. What would you use it for?
• IsTom 12y ago
  If a database is not kill -9 resistant then how can it be power-off resistant?
  • asdfaoeu 12y ago
    Who says it was?
  • jeffdavis 12y ago
    There are ways to misdesign a system such that it is power-off robust but not kill -9 robust. The reason is that power-off means everything dies. Postgres has special code to account for hard kills: it has a SYSV shared memory segment, to which every child attaches. If the parent dies, the children don't have a good way to know, so they might keep running. If you try to start a new postmaster and it sees that there are still processes attached to the shared memory segment (shm_nattch), it will fail to start. Were it not for that code, it would allow you to start a new parent process, leading to chaos as two sets of backends were accessing the same files and shared memory without knowing about eachother.