哪个问题可能导致生产应用程序中的kill -9（在linux中准确）？
我有应用程序做一些定期工作，停止这些需要很长时间，我不在乎是否会中止某些工作 - 工作可以通过新流程完成。那么我可以立即使用kill -9来阻止它，否则会导致严重的操作系统问题？
例如，Unicorn将其用作正常的工作程序：
当你的应用程序出错时，BOFH可以“杀死-9”失控的工作进程，而不必担心会撕毁所有客户端，只有一个。
但是这article声称：
kill（1）的-9（或KILL）参数永远不应该在Unix系统上使用
PS：我知道应用程序无法处理kill -9，但我知道对于应用程序来说它不会导致任何问题，我只是感兴趣它是否会导致操作系统级别的一些问题？ shared memory segments active, lingering sockets对我来说听起来很危险。
答案 0 :(得分：4)
kill -9不会让应用程序有机会干净地关闭。
通常，应用程序可以捕获SIGINT/SIGTERM并干净地关闭（关闭文件，保存数据等）。应用程序无法捕获SIGKILL（与kill -9一起发生），因此无法执行任何此类（可选）清理。
更好的方法是使用标准kill，如果应用程序仍无响应，请使用kill -9。
答案 1 :(得分：2)
kill -9不会导致任何“严重的操作系统问题”。但是这个过程会立即停止，这意味着它可能会使数据处于奇怪的状态。
答案 2 :(得分：1)
这取决于它是什么类型的应用程序。
像数据库这样的东西可能会丢失数据（如果它不会立即将所有数据写入持久性事务日志），或者下次启动需要更长时间，或两者兼而有之。
尽管Crash-only是一个很好的原则，但目前很少有应用程序符合它。
例如，mysql数据库不是“仅崩溃”并且使用kill -9杀死它将导致显着更长的启动时间（比干净关闭），数据丢失或两者兼而有之，这取决于设置（和在某种程度上，运气）。
另一方面，Cassandra实际上鼓励使用kill -9作为关闭机制;它什么都不支持。
答案 3 :(得分：0)
应用程序无法捕获KILL信号。如果应用程序在您将某些复杂数据结构写入磁盘时正在编写，则该结构可能只是半写，导致数据文件损坏。通常最好将一些其他信号（如USER1）作为“停止”信号来实现，因为这可以被捕获并允许应用程序以受控方式关闭。