From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2CA7D1F45F for ; Mon, 6 May 2019 19:07:50 +0000 (UTC) Received: from localhost ([127.0.0.1]:32786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNixl-00038j-OS for normalperson@yhbt.net; Mon, 06 May 2019 15:07:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNisW-000200-5L for bug-gnulib@gnu.org; Mon, 06 May 2019 15:02:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNisU-0001N4-7W for bug-gnulib@gnu.org; Mon, 06 May 2019 15:02:20 -0400 Received: from mail-yw1-f67.google.com ([209.85.161.67]:46867) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNisU-0001Ef-3P for bug-gnulib@gnu.org; Mon, 06 May 2019 15:02:18 -0400 Received: by mail-yw1-f67.google.com with SMTP id a130so5580547ywe.13 for ; Mon, 06 May 2019 12:02:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=wm8M9ZJX0cUk7VoySnZv8galAe3ZZ59c79U5nG/jeOk=; b=Z4RNjP5h9jqzdbNnKPh0afljyDZjhNSPFQ1U1ICKFuiDcBR+XDrFPe402cqIJcSsZ+ xEqqp74QPBIrseZv0UOyB3wGYaWnb/rtc4nv2d5h8BOvmumROMKEa+uMfZBv3hsKg50O NMAwoF3LiCyADTnv+HyK+79D1Y/lyhqXLdlCdw2GyzYeyJvpdhCvC0NRT3/8XIPma7Tm zoXqDG/+f+ojl5PFQuUHQW6UOGGjF6Jl1YjNgfRsmloStLSfhIMlDR8g0C57uZsyBbal KxSao0mo1vI8m9iAeWS0pN/Agg9WbISWHwveboEwc5YPs2JzPCKVnMniexYVzJwZ8Dl3 aD2A== X-Gm-Message-State: APjAAAUbT3drxSrnwnzNV9Ua7FZ9Z/elzgu8tOwhlmh5SGJD8wFznUl5 f/EH02jfjA9N5wCstKVkxwgyjg== X-Google-Smtp-Source: APXvYqyb74vwHn6Ea27XuWzg07eyC0ViRsexp7zplRWoNSLOvq6GS/U04pPA2LbKX6JZstYQIgg4Ww== X-Received: by 2002:a81:2509:: with SMTP id l9mr3327857ywl.223.1557169334107; Mon, 06 May 2019 12:02:14 -0700 (PDT) Received: from vulcan.poochiereds.net (cpe-2606-A000-1100-202A-0-0-0-3A1.dyn6.twc.com. [2606:a000:1100:202a::3a1]) by smtp.gmail.com with ESMTPSA id s13sm3161845ywj.58.2019.05.06.12.02.13 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 06 May 2019 12:02:13 -0700 (PDT) Message-ID: <21309a984400aa98c5da7c6c6926f92a34c923e8.camel@redhat.com> Subject: Re: Why does close_stdout close stdout and stderr? From: Jeff Layton To: Paul Eggert , Florian Weimer , Eric Blake Date: Mon, 06 May 2019 15:02:12 -0400 In-Reply-To: <7e06bc39-0b65-3f96-62f1-1a120bcdcd14@cs.ucla.edu> References: <87muk8d295.fsf@oldenburg2.str.redhat.com> <877ebcd0d7.fsf@oldenburg2.str.redhat.com> <87v9yneqk9.fsf@oldenburg2.str.redhat.com> <7e06bc39-0b65-3f96-62f1-1a120bcdcd14@cs.ucla.edu> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.1 (3.32.1-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.161.67 X-Mailman-Approved-At: Mon, 06 May 2019 15:07:42 -0400 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, NeilBrown Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Mon, 2019-05-06 at 11:53 -0700, Paul Eggert wrote: > 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). > Sure, we have the plumbing to report errors there and some filesystems do it, but those errors don't mean much. See below. > 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/ > You may also be interested in this article too: https://lwn.net/Articles/752613/ Neil points out in the comments that issuing a close() doesn't necessarily initiate any writeback from the kernel. It does on NFS of course, but not on most filesystems. So, a successful return from close() is inconclusive. It just means that the kernel has not hit a writeback error yet, not that the data is truly safe. -- Jeff Layton