bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why does close_stdout close stdout and stderr?


From: Paul Eggert
Subject: Re: Why does close_stdout close stdout and stderr?
Date: Mon, 6 May 2019 11:53:04 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/6/19 5:05 AM, Florian Weimer wrote:

> I've been told that on Linux, close does not report writeback errors.
> So the only way to get a reliable error indicator (beyond what you get
> from the write system call) would be fsync.

Are you sure you asked your expert the right question? I just looked at
the current (5.1) Linux kernel, and though I'm no kernel expert it looks
like the close system call invokes filp_close, which calls
filp->f_op->flush which on NFS is nfs_file_flush, which invokes
vfs_fsync which in turn invokes nfs_file_fsync, and surely this does
what fsync would do (and does more work and error checking than an
ordinary write syscall would do, at any rate).

Admittedly Linux is a real mess in reporting write errors back to the
user, and this has been true for years.[1] That being said, the
longstanding documented tradition is that writeback errors are reported
in later close or fsync calls, and there are suggestions to clean up
this kernel area to get closer to doing what the documentation says.[2]
So until we're pretty sure the matter is settled for Linux, perhaps we'd
better let Gnulib be.

[1] Gunawi HS, Rubio-González C, Arpaci-Dusseau AC, Arpaci-Dusseau RH,
Liblit B. EIO: Error Handling is Occasionally Correct. FAST 2008.
https://www.usenix.org/legacy/event/fast08/tech/gunawi.html

[2] Edge J. Handling writeback errors. LWN.net. 2017-05-04.
https://lwn.net/Articles/718734/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]