Bug 1139444 - rpm badly handles failed write() to stdout
Summary: rpm badly handles failed write() to stdout
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1139805
TreeView+ depends on / blocked
 
Reported: 2014-09-08 22:58 UTC by Jon Stanley
Modified: 2015-03-27 09:47 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
: 1139805 (view as bug list)
Environment:
Last Closed: 2015-03-27 09:47:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jon Stanley 2014-09-08 22:58:13 UTC
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 23:04:50 UTC
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 10:25:23 UTC
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 10:40:31 UTC
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 15:19:13 UTC
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 10:08:03 UTC
(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 09:47:13 UTC
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.