简体繁体 English

当fd是常规文件时，linux系统调用read（fd，buf，count）返回的结果是否小于count？

[英]Does the linux system call read(fd, buf, count) return less than count when fd is a regular file?

原文 2015-02-13 13:50:13 9 2 c/ linux/ system-calls

When we call read(fd, buf, count) on Linux, can the return value of the system (function) call be less than count other than the scenario where there were fewer bytes to the end-of-file? 当我们在Linux上调用read(fd, buf, count)时，系统（函数）调用的返回值是否可以小于count，而不是文件末尾的字节数较少的情况？

I looked it up in the man page, it says 我在手册页中查找它，上面写着

"On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal ." “成功后，将返回读取的字节数（零表示文件末尾），并且文件位置以该数字前移。如果此数目小于请求的字节数，这不是错误；这可能发生在例如，因为现在实际上实际可用的字节较少（也许是因为我们接近文件末尾，或者因为我们正在从管道或终端read() ）， 或者因为read()被信号中断了 。”

So here is my question: How can read() on a regular file be interrupted by a signal? 所以这是我的问题：如何通过信号中断常规文件上的read() ？ By what possible signals? 通过什么可能的信号？

2 个解决方案

This documentation page specifies which calls can be interrupted by a signal, and read() is on the list. 该文档页面指定哪些调用可以被信号中断，并且read()在列表中。 You have to enable this behavior in Linux (with SA_RESTART ), it's not on by default. 您必须在Linux中使用SA_RESTART启用此行为，默认情况下未启用。

Yes, read() can be interrupted by a signal. 是的， read()可以被信号中断。 But not when the process is reading from a descriptor that belongs to file on file system. 但是，当进程正在从属于文件系统上文件的描述符中读取时，则不是这样。

When process calls read() on file it enters a so-called uninterruptible sleep . 当进程在文件上调用read() ，它将进入所谓的不间断睡眠 。 In this mode process will not handle any signals until system call is completed. 在这种模式下，直到系统调用完成，进程才会处理任何信号。 Either because of some error or when requested data was read. 由于某些错误或在读取请求的数据时。

Note : when process is in an uninterruptible sleep you can't even terminate it with SIGKILL signal. 注意：当进程处于不间断的睡眠状态时，您甚至无法使用SIGKILL信号终止它。 Or in the other words kill $pid -9 will have no effect. 否则换句话说， kill $pid -9将无效。

In this question there is an explanation of an uninterruptible sleep: What is an uninterruptable process? 在这个问题中，有一个不间断睡眠的解释： 什么是不间断的过程？

Note further : there is and interesting real-life cases when hard drive experiences failure and all processes that either trying to write data to that disk (File System) or to read from it are stuck and cannot be killed by any means other than rebooting a system. 请进一步注意 ：在现实生活中，有趣的情况是硬盘驱动器出现故障，并且所有试图将数据写入该磁盘（文件系统）或从中读取数据的进程都被卡住，并且除了重新启动硬盘外，无法通过其他任何方式杀死系统。 This is also true for volumes mounted over a network, such as NFS. 对于通过网络（例如NFS）安装的卷也是如此。

Edit: as psmears has pointed out, read() can be interrupted if reading from file that is on the volume, mounted via NFS iff intr mount option was specified. 编辑：如psmears所指出的，如果指定了通过NFS的iff intr挂载选项挂载的卷上的文件读取，则read()可能会中断。