Bug 1139444 - rpm badly handles failed write() to stdout
rpm badly handles failed write() to stdout
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1139805
  Show dependency treegraph
 
Reported: 2014-09-08 18:58 EDT by Jon Stanley
Modified: 2015-03-27 05:47 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1139805 (view as bug list)
Environment:
Last Closed: 2015-03-27 05:47:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jon Stanley 2014-09-08 18:58:13 EDT
Description of problem:

If stdout is being redirected to a file, and the filesystem is full, rpm will silently fail despite write() returning -ENOSPC

<much snippage from strace>
write(1, "grep-2.18-1.fc20.x86_64\n", 24) = -1 ENOSPC (No space left on device)

Version-Release number of selected component (if applicable):

rpm-4.11.2-2.fc20.x86_64

How reproducible: 100%

Steps to Reproduce:
1. Make a filesystem, fill it up (I used a small loopback filesystem to reproduce)
2. rpm -qa > testfile
3. Watch the file either not have all of the expected output (i.e. writes succeeded prior to -ENOSPC) or be 0 bytes

rpm should inform the user about the error, as other utilities do. For example:

$ id  > /mnt/test/test14
id: write error: No space left on device
Comment 1 Jon Stanley 2014-09-08 19:04:50 EDT
Forgot to list the actual problematic sequence of commands, but you could probably figure it out. But for completeness sake:

$ rpm -qa > /mnt/test/test15 ; echo $?
0
$ ls -l /mnt/test/test15
-rw-rw-r--. 1 jstanley jstanley 0 Sep  8 19:02 /mnt/test/test15
Comment 2 Panu Matilainen 2014-09-09 06:25:23 EDT
Yup... from the rpm logging function:

    (void) fputs(rpmlogLevelPrefix(rec->pri), msgout);

    (void) fputs(rec->message, msgout);
    (void) fflush(msgout);

These go back 14 years almost to date, the (void) warning silencers are half a year younger so its not exactly a new bug :) Thanks for reporting though.
Comment 3 Panu Matilainen 2014-09-09 06:40:31 EDT
Just FWIW, rpmlog() does not return an error code, so without API-changes this is fixable only to the extent of logging an error from the logger function ... unless the error came from writing to stderr, in which case reporting an error is going to be a bit difficult anyway.
Comment 4 Jon Stanley 2014-09-09 11:19:13 EDT
Hmm, if I'm reading this correctly that means that there's no way for the rpm command to exit with a non-zero exit code without API changes?
Comment 5 Panu Matilainen 2014-09-23 06:08:03 EDT
(In reply to Jon Stanley from comment #4)
> Hmm, if I'm reading this correctly that means that there's no way for the
> rpm command to exit with a non-zero exit code without API changes?

Possibly. Lets just say in any case its more complicated than "just adding a missing check for return code". The error occurs within rpms logging system, and there are some complications in logging an error about failure to log :)
Comment 6 Ľuboš Kardoš 2015-03-27 05:47:13 EDT
As it was said it is not easy to exit with non-zero exit code so I added patch to upstream that in case of error in logging tries to display that error on stderr but rpm exit code is not affected.

Note You need to log in before you can comment on or make changes to this bug.