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

Question

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?

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."

So here is my question: How can read() on a regular file be interrupted by a signal? By what possible signals?

Note that this is a more interesting question if you consider small values of count verses large values. — William Pursell, Feb 13 '15 at 14:03
Even if a particular kernel did guarantee that it wouldn't return less data, why would you make that assumption? The `read()` function gives you the number of bytes returned. Use it. When a function returns a value or a possible error code, code as if it might return anything. Don't assume anything. — Zan Lynx, Jul 07 '15 at 04:02

score 4 · Answer 1 · edited May 23 '17 at 10:26

4

Yes, read() can be interrupted by a signal. 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. 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. Or in the other words kill $pid -9 will have no effect.

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.

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.

edited May 23 '17 at 10:26

Community

1
1

answered Feb 13 '15 at 14:05

GreenScape

7,191
2
34
64

1

This is wrong: there are cases where a `read()` on a filesystem file *can* be interrupted. The classic example is an NFS mount mounted with the `intr` option. – psmears Feb 13 '15 at 14:12
@psmears, please, read documentation more carefully: `intr — Allows NFS requests to be interrupted if the server goes down or cannot be reached`. This means that OS (driver) will not wait indefinitely. This is not the same as sending some signal to a process reading/writing from a file from a mounted volume will result in syscall being interrupted. – GreenScape Feb 13 '15 at 14:17
1

No, you read the documentation more carefully ;-) `soft` means the driver will time out. `intr` (depending on kernel version) allows the user to interrupt (signal) the process. From the docs: "If intr is specified, system calls return EINTR if an in-progress NFS operation is interrupted by a signal. " – psmears Feb 13 '15 at 14:22

score 2 · Answer 2 · answered Feb 13 '15 at 13:57

2

This documentation page specifies which calls can be interrupted by a signal, and read() is on the list. You have to enable this behavior in Linux (with SA_RESTART), it's not on by default.

answered Feb 13 '15 at 13:57

unwind

391,730
64
469
606

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

2 Answers2