给定SIGTERM时，可以在多大程度上依赖于写入磁盘? [英] To What Extent Can One Rely on Writing to Disk When SIGTERM is Given?
问题描述
我正在为Linux开发，并且有一个守护进程，该守护进程在被杀死时应写入磁盘.可以将守护程序配置为侦听 SIGTERM 并在收到该信号时将其写入磁盘.
我还熟悉登录管理器.侦听 SIGTERM 所得到的代码比禁止关机和侦听 PrepareForShutdown 信号要简单得多. SIGTERM 的另一个优点是，即使系统关闭，它也可以处理守护进程被有礼貌地杀死的情况.
但是，我不确定依靠关机时内核发送的 SIGTERM 信号有多安全.在关闭时， SIGTERM 是否总是以足够的时间发送到每个进程以执行对磁盘的小的写入(小于1 kB)?
我关心的一个问题是，我可能有足够的时间在某些硬件上写磁盘，而在其他硬件上没有写磁盘，因此似乎很难测试.对于 PrepareForShutdown 信号也可以这样说，但是至少要留出足够的时间进行磁盘写操作是该信号契约的一部分.我的问题是，对于每个代码在关闭时收到的 SIGTERM 信号，是否可以说相同的话.
仔细阅读 write(2)一些数据到文件系统.这是为了将数据写入磁盘(它可能保留在内核文件系统缓冲区中).阅读 sync(2)& fsync(2).
您不能(在所有情况下)确保将数据写入磁盘(尤其是在断电时).
我不会打扰并使用 syslog(3)(即让我的 SIGTERM 处理程序设置一个 volatile sigatomic_t 标志，然后在其他位置测试该标志；在终止调用 syslog ...时).然后记录您的程序正在终止时写入系统日志，并负责确保将系统日志(写入到某个磁盘，可能位于网络上)写入系统管理员.
关机的具体行为主要是系统管理员的问题.它实际上取决于实际系统(包括linux发行版和硬件)和sysadmin的技能.有些文件系统是远程文件系统，或者(对于廉价的USB密钥来说)很慢的文件系统(并且对它们的写入 可能会丢失).
想象一下，还有一个有问题的守护程序的系统(不是您的守护程序，而是其他)，需要很长时间才能终止.然后，您的守护程序可能没有时间做明智的事情.因此，您必须信任系统管理员.
我不明白您为什么要问您的问题.这取决于整个系统的管理和设置方式.在数百万美元的服务器和笔记本电脑上，确实是不同的.
I am developing for Linux and have a daemon that should write to disk when it is killed. The daemon could be configured to listen to SIGTERM and write to disk when that signal is received.
I am also familiar with the PrepareForShutdown D-Bus signal issued by the login manager. Listening to SIGTERM results in simpler code than inhibiting shutdown and listening to the PrepareForShutdown signal. Another advantage of SIGTERM is that it handles cases where the daemon is politely killed even though the system shuts down.
However, I am not sure how safe it is to rely on the SIGTERM signal being sent by the kernel at shutdown. At shutdown is SIGTERM always sent to every process with enough time to perform a small (< 1 kB) write to disk?
One concern I have is that I might have enough time to write to disk on some hardware but not on others, so it seems difficult to test. The same could be said of the PrepareForShutdown signal, but at least allowing enough time for disk writes is part of the contract of that signal. My question is whether the same can be said for the SIGTERM signal every process receives on shutdown.
Read carefully signal(7) - so you can't fprintf from a signal handler. Often the most sensible thing to do is to set some volatile sigatomic_t variable in the signal handler, and test that variable outside it.
The point is not only to write(2) some data to a file system. It is to get the data written to the disk (it might stay in kernel filesystem buffers). Read sync(2) & fsync(2).
You cannot (in all cases) be sure that data is written to the disk (especially on power outage).
I would not bother and use syslog(3) (i.e. have my SIGTERM handler set a volatile sigatomic_t flag, and later test that flag elsewhere; on termination call syslog...). Then document that your program is writing to the system log on termination, and leave the responsability of ensuring that the system log is written (to some disk somewhere, perhaps on the network) to the sysadmin.
The concrete behavior of shutdown is mostly a sysadmin issue. It really depends upon the actual system (including linux distribution and hardware) and the sysadmin's skills. Some file systems are remote or (for cheap USB keys) very slow file systems (and writing to them can be lost).
Imagine also a system with a buggy daemon (not yours but something else) which take ages to terminate. Then your daemon might not have time to do something sensible. So you have to trust the sysadmin.
I don't understand why you are asking your question. It depends upon how the entire system is administrated and set up. It really is different on million dollars servers and on a laptop.
这篇关于给定SIGTERM时，可以在多大程度上依赖于写入磁盘?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
