Kill -9 和生产应用
哪个问题会导致生产应用程序中的 kill -9（确切地说是在 Linux 中）？
我有一些定期工作的应用程序，停止这些工作需要很长时间，而且我不在乎某些工作是否会被中止 - 工作可以通过新流程完成。那么我可以使用 kill -9 立即停止它吗？否则这可能会导致严重的操作系统问题？
例如，Unicorn，将其用作正常工作流程：
当您的应用程序出现问题时，BOFH 可以“杀死 -9”失控的工作进程，而不必担心会破坏所有客户端（仅一个）。
但这篇文章声称：
kill(1) 的 -9（或 KILL）参数永远不应该在 Unix 系统上使用
PS：我知道 kill -9 无法由应用程序处理，但我知道对于可能的应用程序来说它不会引起任何问题，我只是想知道它会在操作系统级别引起一些问题吗？ 共享内存段活动，挥之不去的套接字对我来说听起来很危险。
Which problem can cause kill -9 in production application (in linux to be exact)?
I have application which do some periodical work, stopping these takes long time, and I don't care if some jobs will be aborted - work can be finished by new processes. So can I use kill -9 just to stop it immediately or this can cause serious OS problems?
For example, Unicorn, uses it as normal working procedure:
When your application goes awry, a BOFH can just "kill -9" the runaway worker process without worrying about tearing all clients down, just one.
But this article claims:
The -9 (or KILL) argument to kill(1) should never be used on Unix systems
PS: I understand that kill -9 cannot be handled by application, but I know that for may application it doesnt cause any problems, I just intrested can it cause some problems on OS level? shared memory segments active, lingering sockets sounds dangerous to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
kill -9不会给应用程序彻底关闭的机会。通常应用程序可以捕获
SIGINT/SIGTERM并干净地关闭（关闭文件、保存数据等）。应用程序无法捕获SIGKILL（与kill -9一起发生），因此它无法执行任何此类（可选）清理操作。更好的方法是使用标准
kill，如果应用程序仍然无响应，则使用kill -9。kill -9doesn't give an application a chance to shut down cleanly.Normally an application can catch a
SIGINT/SIGTERMand shut down cleanly (close files, save data etc.). An application can't catch aSIGKILL(which occurs with akill -9) and so it can't do any of this (optional) cleanup.A better approach is to use a standard
kill, and if the application remains unresponsive, then usekill -9.kill -9不会导致任何“严重的操作系统问题”。但该过程将立即停止，这意味着它可能会使数据处于奇怪的状态。kill -9won't cause any "serious OS problems". But the process will stop immediately, which means it might leave data in an odd state.这取决于它是什么类型的应用程序。
像数据库这样的东西可能会丢失数据（如果它没有立即将所有数据写入持久事务日志），或者下次启动需要更长的时间，或者两者兼而有之。
虽然Crash-only是一个很好的原则，但目前很少有应用程序遵循它。
例如，mysql 数据库不是“仅崩溃”，使用kill -9 杀死它会导致启动时间显着延长（比干净关闭）、数据丢失或两者兼而有之，具体取决于设置（并且在某种程度上） ，运气）。
另一方面，Cassandra 实际上鼓励使用kill -9 作为关闭机制；它不支持其他任何东西。
It depends what kind of application it is.
Something like a database may either lose data (if it does not write all its data to a persistent transaction log at once), or take longer to start up next time, or both.
Although Crash-only is a good principle, few application currently conform to it.
For example, the mysql database is not "crash only" and killing it with a kill -9 will result in either significantly longer startup time (than a clean shutdown), data loss, or both, depending on the settings (and to some extent, luck).
On the other hand, Cassandra actually encourages the use of kill -9 as a shutdown mechanism; it supports nothing else.
应用程序无法捕获 KILL 信号。如果当您终止应用程序时，应用程序正在将一些复杂的数据结构写入磁盘，则该结构可能只写入了一半，从而导致数据文件损坏。通常最好实现一些其他信号，例如 USER1 作为“停止”信号，因为这可以被捕获并允许应用程序以受控方式关闭。
The KILL signal cannot be caught by the application. If the application is in the middle of writing some complex data structure to disk when you kill it, the structure may be only half-written, resulting in a corrupted data file. it is usually best to implement some other signal such as USER1 as the "stop" signal, as this can be caught and allows the application to shut down in a controlled manner.