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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
