* Unexpected behaviour writing to /dev/full @ 2018-08-02 17:51 Jonny Prouty 2018-08-02 18:03 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Jonny Prouty @ 2018-08-02 17:51 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 1947 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behaviour writing to /dev/full 2018-08-02 17:51 Unexpected behaviour writing to /dev/full Jonny Prouty @ 2018-08-02 18:03 ` Rich Felker 2018-08-02 18:05 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2018-08-02 18:03 UTC (permalink / raw) To: Jonny Prouty; +Cc: musl 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. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behaviour writing to /dev/full 2018-08-02 18:03 ` Rich Felker @ 2018-08-02 18:05 ` Rich Felker 2018-08-02 18:32 ` Jonny Prouty 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2018-08-02 18:05 UTC (permalink / raw) To: Jonny Prouty; +Cc: musl 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behaviour writing to /dev/full 2018-08-02 18:05 ` Rich Felker @ 2018-08-02 18:32 ` Jonny Prouty 2018-08-02 18:53 ` Jonny Prouty 0 siblings, 1 reply; 6+ messages in thread From: Jonny Prouty @ 2018-08-02 18:32 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 3605 bytes --] 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" <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 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 [-- Attachment #2: Type: text/html, Size: 5333 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behaviour writing to /dev/full 2018-08-02 18:32 ` Jonny Prouty @ 2018-08-02 18:53 ` Jonny Prouty 2018-08-02 19:51 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Jonny Prouty @ 2018-08-02 18:53 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 4529 bytes --] 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 <jonathanprouty@gmail.com> 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" <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 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 > > > [-- Attachment #2: Type: text/html, Size: 6734 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unexpected behaviour writing to /dev/full 2018-08-02 18:53 ` Jonny Prouty @ 2018-08-02 19:51 ` Rich Felker 0 siblings, 0 replies; 6+ messages in thread From: Rich Felker @ 2018-08-02 19:51 UTC (permalink / raw) To: Jonny Prouty; +Cc: musl On Thu, Aug 02, 2018 at 02:53:26PM -0400, Jonny Prouty wrote: > 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 <jonathanprouty@gmail.com> 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. What exit status the application wants to use is up to the application, but as a matter of quality of design, it only makes sense to return a failure exit code if the primary function the command was supposed to perform did not work. Programs where the primary function is their output, and the output is intended to be consumable/parsable by other programs, should definitely exit with nonzero status if they fail to write the full output, since bad things could happen if a script acts on their incomplete output thinking it was complete and correct. But there's really no good argument that failure to print a usage message needs to be considered an error, and treating failure to print unimportant status output as an error when the primary function of the command already succeeded is probably a really bad idea. In any case, libc has no control over the exit status; it's the application's choice what to return. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-02 19:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-02 17:51 Unexpected behaviour writing to /dev/full Jonny Prouty 2018-08-02 18:03 ` Rich Felker 2018-08-02 18:05 ` Rich Felker 2018-08-02 18:32 ` Jonny Prouty 2018-08-02 18:53 ` Jonny Prouty 2018-08-02 19:51 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).