On Thu, Aug 31, 2023 at 11:12:59AM +0200, Laszlo Ersek wrote:
On 8/31/23 10:02, Richard W.M. Jones wrote:
>
> On Wed, Aug 30, 2023 at 05:21:19PM -0500, Eric Blake wrote:
>> I hit another transient failure in libnbd CI when a poorly-written
>> eval script did not consume all of stdin during .pwrite. As behaving
>> as a data sink can be a somewhat reasonable feature of a
>> quickly-written sh or eval plugin, we should not be so insistent as
>> treating an EPIPE failure as an immediate return of EIO to the client.
>
> I was thinking about this over night, and came to the conclusion that
> it's always fine to ignore EPIPE errors.
Interesting; I formed the opposite impression!
It took me a couple of tries to realize the subtle distinction.
If the child process (aka the plugin script) dies with SIGPIPE (and we
intentionally do signal(SIGPIPE, SIG_DFL) before exec'ing the child
process, as it is notoriously hard to undo an inherited ignored
SIGPIPE in shell), the parent process will see WIFSIGNALED and treat
that as an EIO error to the NBD client.
If the child process chooses to ignore SIGPIPE, but then sees its own
EPIPE failure and exits with non-zero status as a result, the parent
process will see the non-zero exit status and report an appropriate
error to the NBD client (if it can parse an error name out of the
plugin's stderr output, it uses that; otherwise it uses EIO).
But if the parent process sees EPIPE, that merely means that the
plugin script doesn't care to finish consuming stdin. It is
indeterminate at that point whether the child has a reason for
ignoring the pipe, so it is inappropriate to blindly treat failure to
write to the child as a reason to claim the child would have failed
with EIO, without giving the child a chance to exit() (or die by
signal) first.
>
> So my counter-proposal (coming soon) is going to simply turn the EPIPE
> error into a debug message and discard the rest of the write buffer.
Yes, I liked your counter-proposal better than my attempt.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:
qemu.org |
libguestfs.org