From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13101 Path: news.gmane.org!.POSTED!not-for-mail From: Jonny Prouty Newsgroups: gmane.linux.lib.musl.general Subject: Re: Unexpected behaviour writing to /dev/full Date: Thu, 2 Aug 2018 14:53:26 -0400 Message-ID: References: <20180802180306.GL1392@brightrain.aerifal.cx> <20180802180509.GM1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003ff96f05727854f6" X-Trace: blaine.gmane.org 1533235910 17048 195.159.176.226 (2 Aug 2018 18:51:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2018 18:51:50 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13117-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 02 20:51:46 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1flIhN-0004Jx-EN for gllmg-musl@m.gmane.org; Thu, 02 Aug 2018 20:51:45 +0200 Original-Received: (qmail 21516 invoked by uid 550); 2 Aug 2018 18:53:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20471 invoked from network); 2 Aug 2018 18:53:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mds7nUL7ndg1OS3GGU6IdzvLsZ12z02dpEHIp/LWteU=; b=aclJsPjHAnSAG5ztG9xwVmu6Pm9yU/jurpuJjQ9Ni3i8qTp0gzDKwJsLcCkhZ7TOu5 03p6KXu7dDbqlUyYvHi3Azkto4woIhOa6jswRxjTaEKvMnQGZhXzFoq0AVXUMT7KQsIK MZ4pj0JouR4WRuPZpjNjJk0zh/CllSODrmVEQEYaqzTt4GbYXklEezjbj5Isqo6zixxu PUZ2AVD3+m7Q50L3LFrHiJqswfC61YHmPca/1Tp+3zdn8/4I30KzuqxRHuUTVHZAQkMN zHdme5iy8cn81CEbhMBG60qORIQouCtNMfEXTnQrRQwoW+w8wCLgC4S7TXxyUjXVJzfb oFfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mds7nUL7ndg1OS3GGU6IdzvLsZ12z02dpEHIp/LWteU=; b=OcLdShzrDv7svf+1N9P/zVnhAKPwUpfiQR14t/5nZpz7PluSn/eBRkDZwJI0UBHmE7 Uvfx39NWcYFkEboVaBcjtAh9o9fbWqZSQjTXd10VKliHcJEJpXXmpn5z0u5Ge+Zec9g8 fA2ffzyy1TUwoCJc0xz1osU8Y0Z8bGA41f5do18MAu8YuZG4FY0PspN9Gka9MNvNcRx+ RUuG9JOyFbziWY1xQyqdAuKdM657TlOhP9xJ/9eUt1xffNGYY6w1IJhewXntWhDylFEm y1vUiW2IImejMO3xsuwO5U3FAMAefDG+iLN3BpGcjcC9GzlrAYvtcktRUQ1ilzxdLpa9 wfpA== X-Gm-Message-State: AOUpUlHicKDz/526U7VnPTY9GmPaUM/aECT2/wfPlf1t5+s6z//j8F5z Mdutq6mXA+foSwSHbZzbQN+b+vrredHl9tU4hpdVrA== X-Google-Smtp-Source: AAOMgpcJHj/MLSfwIKrAmeg7SbJ+Bewkw8jF+7fe2mLOtzTZO17+LPler6rcmp9YNziCnqjCu6kf2ayDM/qckNWqp44= X-Received: by 2002:a2e:4557:: with SMTP id s84-v6mr2986891lja.47.1533236018671; Thu, 02 Aug 2018 11:53:38 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13101 Archived-At: --0000000000003ff96f05727854f6 Content-Type: text/plain; charset="UTF-8" Or it could be that it is just extremely commonplace to NOT check whether you were able to successfully write to stdout before exiting. In which case you are absolutely correct, this would be a bug in busybox (and similar bugs in many other programs). I just tested both of the following commands on systems using musl, uclibc-ng, and glibc, all returned 0: # bm's vim # vim --help &> /dev/full; echo $? 0 # gnu tar # tar --help &> /dev/full; echo $? 0 I'm leaning towards this is just the app didn't check whether their write to stdout was successful. Thanks for your help Rich. P.S. Please excuse my brevity, I am corresponding from my phone. On Thu, Aug 2, 2018, 2:32 PM Jonny Prouty wrote: > I am indeed using busybox ls, but I can get similar behavior when running > things that aren't shell builtins. For instance in Alpine if you run: > > # /bin/rc-status > /dev/full ; echo $? > 0 > > or > > #/sbin/update-conf --help &> /dev/full ; echo $? > 0 > > Some programs do behave as I'd expect, however > > # /sbin/apk --help> /dev/full ; echo $? > 1 > > Something seems amiss. > > P.S. Please excuse my brevity, I am corresponding from my phone. > > On Aug 2, 2018 2:05 PM, "Rich Felker" wrote: > > On Thu, Aug 02, 2018 at 02:03:06PM -0400, Rich Felker wrote: > > On Thu, Aug 02, 2018 at 01:51:21PM -0400, Jonny Prouty wrote: > > > Hello all, > > > > > > I have a question regarding the interaction of atexit() (I believe its > > > atexit, anyways) and exit statuses. First the issue I stumbled across, > so > > > you'll see where I'm coming from: > > > > > > # ls "$HOME" > /dev/full; echo $? > > > 0 > > > # echo "$HOME" > /dev/full; echo $? > > > 1 > > > > > > I expected neither command to return 0 since ultimately an ENOSPC > should be > > > returned when writing to /dev/full. Indeed, failure statuses are > returned > > > for 'ls' and 'echo' derived from binaries built against glibc. I tried > to > > > walk the musl code and it looks like the exit codes are being set (or > not > > > set) by atexit(). In the case of 'ls', it seems that it was able to > > > successfully get a directory listing, but the final fflush() of the > output > > > buffer fails with ENOSPC, but that is lost because it happened as a > result > > > of some function that was registered with atexit. I *think*. This > > > interpretation is also borne of a desire to be able to ascribe this to > the > > > undefined re-entrant exit behaviour described in "Re-entrancy of exit" > at > > > https://wiki.musl-libc.org/functional-differences-from-glibc.html. > 'echo' > > > would be failing (as expected) because presumably stdout is flushed > before > > > it exits. > > > > > > Regardless, the fact that writing to /dev/full can return success seems > > > wrong. Any thoughts are much appreciated. Please CC me on any > responses. > > > Thanks! > > > > > > Jonny > > > > > > P.S. > > > musl behaves similarly to uClibc and uClibc-ng in my testing. > > > > What versions of ls and echo are you using? Busybox? GNU coreutils? > > (Note that echo is probably a shell builtin in your shell; you need to > > execute /bin/echo or similar to get the real echo program.) > > > > There is nothing musl can do directly to change the exit status; > > failure when writing/flushing a file is an error returned to the > > application, which determines its own exit status, not something that > > automatically changes the return value of main/argument passed to > > exit(). > > > > Do you mean the program is trying to detect flush failure and set an > > exit status from an atexit handler it installed? That's what gnulib > > stuff does, if I recall, and it may be how the GNU coreutils ls and > > other programs handle termination status. It's not a very good way to > > do it, but it should work if they're doing things right. If they're > > doing something that's unspecified or undefined from the atexit > > handler, such as calling exit again (reentrantly), that's an > > application bug. > > > > If you tell us which versions of the utilities you're using, I can > > look into it a bit more. > > For what it's worth, I just tested and got the behavior you saw with > busybox ls. With GNU coreutils ls linked against musl, I get a nonzero > exit status. So if you're using a busybox-based distro like Alpine and > didn't install GNU coreutils in place of it, this very well might just > be busybox failing to report the error, which should probably be > reported as a bug in busybox. > > > Rich > > > --0000000000003ff96f05727854f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Or it could be that it is just extremel= y commonplace to NOT check whether you were able to successfully write to s= tdout before exiting. In which case you are absolutely correct, this would = be a bug in busybox (and similar bugs in many other programs). I just teste= d both of the following commands on systems using musl, uclibc-ng, and glib= c, all returned 0:

# bm&= #39;s vim
# vim --help &> /dev/full; echo $?<= /div>
0

# gnu tar
# tar --help &> /dev/full; echo $?=
0

I'm leaning towards this is just the app didn't check whether the= ir write to stdout was successful. Thanks for your help Rich.


P.S. Please excuse my brevity, I am= corresponding from my phone.

On Thu, Aug 2, 2018, 2:32 PM Jonny Prouty <jonathanprouty@gmail.com> wrote:
I am indeed using busyb= ox ls, but I can get similar behavior when running things that aren't s= hell builtins.=C2=A0 For instance in Alpine if you run:
# /bin/rc-status > /dev/full ; echo $?
0

or

#/sbin/update-conf --help &= amp;>=C2=A0/dev/full ; echo $?
0

Some programs do behave as I'd e= xpect, however

# /sbin/a= pk --help> /dev/full ; echo $?
1

Something seems amiss.

P.S. Please excuse my brevity, I am corresponding from my pho= ne.

On Aug 2, 2018 2:05 PM, "Rich Felker" <dalias@libc.org>= ; wrote:
On Thu, Aug 02, 2018 at= 02:03:06PM -0400, Rich Felker wrote:
> On Thu, Aug 02, 2018 at 01:51:21PM -0400, Jonny Prouty wrote:
> > Hello all,
> >
> > I have a question regarding the interaction of atexit() (I believ= e its
> > atexit, anyways) and exit statuses. First the issue I stumbled ac= ross, so
> > you'll see where I'm coming from:
> >
> > # ls "$HOME" > /dev/full; echo $?
> > 0
> > # echo "$HOME" > /dev/full; echo $?
> > 1
> >
> > I expected neither command to return 0 since ultimately an ENOSPC= should be
> > returned when writing to /dev/full. Indeed, failure statuses are = returned
> > for 'ls' and 'echo' derived from binaries built a= gainst glibc. I tried to
> > walk the musl code and it looks like the exit codes are being set= (or not
> > set) by atexit(). In the case of 'ls', it seems that it w= as able to
> > successfully get a directory listing, but the final fflush() of t= he output
> > buffer fails with ENOSPC, but that is lost because it happened as= a result
> > of some function that was registered with atexit. I *think*. This=
> > interpretation is also borne of a desire to be able to ascribe th= is to the
> > undefined re-entrant exit behaviour described in "Re-entranc= y of exit" at
> > htt= ps://wiki.musl-libc.org/functional-differences-from-glibc.html. 'ec= ho'
> > would be failing (as expected) because presumably stdout is flush= ed before
> > it exits.
> >
> > Regardless, the fact that writing to /dev/full can return success= seems
> > wrong. Any thoughts are much appreciated. Please CC me on any res= ponses.
> > Thanks!
> >
> > Jonny
> >
> > P.S.
> > musl behaves similarly to uClibc and uClibc-ng in my testing.
>
> What versions of ls and echo are you using? Busybox? GNU coreutils? > (Note that echo is probably a shell builtin in your shell; you need to=
> execute /bin/echo or similar to get the real echo program.)
>
> There is nothing musl can do directly to change the exit status;
> failure when writing/flushing a file is an error returned to the
> application, which determines its own exit status, not something that<= br> > automatically changes the return value of main/argument passed to
> exit().
>
> Do you mean the program is trying to detect flush failure and set an > exit status from an atexit handler it installed? That's what gnuli= b
> stuff does, if I recall, and it may be how the GNU coreutils ls and > other programs handle termination status. It's not a very good way= to
> do it, but it should work if they're doing things right. If they&#= 39;re
> doing something that's unspecified or undefined from the atexit > handler, such as calling exit again (reentrantly), that's an
> application bug.
>
> If you tell us which versions of the utilities you're using, I can=
> look into it a bit more.

For what it's worth, I just tested and got the behavior you saw with busybox ls. With GNU coreutils ls linked against musl, I get a nonzero
exit status. So if you're using a busybox-based distro like Alpine and<= br> didn't install GNU coreutils in place of it, this very well might just<= br> be busybox failing to report the error, which should probably be
reported as a bug in busybox.


Rich

--0000000000003ff96f05727854f6--