Description of problem: While running dracut I see consistently "cat: write error: Broken pipe" dracut /boot/initramfs_file.img while debugging I found it comes from /usr/bin/lsinitrd and to be precisely from a pipe to 'read'. I can reproduce the problem with 'read' as root, not as regular user. Version-Release number of selected component (if applicable): bash-4.3.42-3.fc23.x86_64 How reproducible: pipe something big to 'read' as user 'root' Steps to Reproduce: 1. become regular user 2. run: cat /dev/random | (read -N 6 test; echo $test) 3. see some random output but no error 4. become root 5. run: cat /dev/random | (read -N 6 test; echo $test) 6. see some random output and error: cat: write error: Broken pipe Actual results: cat: write error: Broken pipe Expected results: no error Additional info:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Nice pointer. Did you use sudo? Try running the same when logging in as root. Then $ yes | true does no longer catch a SIGPIPE and neither does dracut. However, it seems that dnf still suffers from cat: write error: Broken pipe ... does it call sudo? Interesting bug btw. I would have expected that coreutils are robust against SIGPIPE. I guess (wildly) sudo manipulates the default settings for sockets so that they rise SIGPIPE... hth
As you can see I can only reproduce the error with 'su' not 'sudo su' [justin@localhost ~] $ cat /dev/random | (read -N 6 test; echo $test) B�O�u�&����Q [justin@localhost ~] $ su Password: [root@localhost justin] # cat /dev/random | (read -N 6 test; echo $test) AܻM�̻E cat: write error: Broken pipe [root@localhost justin] # exit exit [justin@localhost ~] $ sudo su [root@localhost justin] # cat /dev/random | (read -N 6 test; echo $test) AצF�q
same for 'yes | true' [justin@localhost ~] $ yes | true [justin@localhost ~] $ su Password: [root@localhost justin] # yes | true yes: standard output: Broken pipe [root@localhost justin] # exit exit [justin@localhost ~] $ sudo su [root@localhost justin] # yes | true [root@localhost justin] #
Not for me. How about the console? The same problem seems to happen with remote shells, but I cannot test this here. Note, that this problem is somehow minor, since it does not cause an actual error, it is just a misplaced error message. So maybe the severity should be "low". I realized that it is the opposite way, that as normal user SIGPIPE is triggered before EPIPE is returned. As normal user: $ ( trap "" PIPE ; yes | true ) yes: standard output: Broken pipe And, just for fun: $ yes `seq 10000` | true yes: standard output: Broken pipe yes: write error The second error is from the atexit handler which .... ok. I am not going to debug "yes".
oh no. This is a bug in sudo. $ sudo # kill -PIPE $$ $ expected result: $ sudo # kill -PIPE $$ $ That is, sudo does not forward SIGPIPE. Btw, arguably, "yes" should ignore EPIPE, since this is the only reasonable way to exit "yes".
ehm. too late in the night $ sudo # kill -PIPE $$ # but expected: $ sudo # kill -PIPE $$ $ sorry for the spam.
This is a duplicate of Bug 1268958 which is a clone of bug #1094548 which I cannot access. As far as I can see, this bug is fixed and then reintroduced periodically to sudo. Which matches my overall impression of sudo :( The bug in yes appeared also in other places, but I cannot find a bug report for it. But I will not open a bug report against "yes"...
Ok, possibly you see something I don't see. I thought my examples showed 'su' to reproduce the error instead of 'sudo' Just "sudo" does not work for me as you show in your example, it wants arguments. I seem to get the expected behavior; [justin@localhost ~] $ sudo -s [sudo] password for justin: [root@localhost justin] # kill -PIPE $$ [justin@localhost ~] $ Now also tested a direct root console login (no sudo or su), both the "yes | true" and 'cat /dev/random | (read -N 6 test; echo $test)' produce the error too. > $ sudo > # kill -PIPE $$ > # > > but expected: > > $ sudo > # kill -PIPE $$ > $
Yes, sorry, I have a bit of a special confguration. It happens for me when I have in /etc/sudoers myself localhost=(root) NOPASSWD: /bin/bash and I run $ sudo bash # kill -PIPE $$ # where sudo-1.8.15-2.fc23.x86_64 util-linux-2.28-2.fc23.x86_64 I would have guessed that it is due to a a forgotten SIGPIPE handler, but now that you say it also happens when logging in as root, it is strange. Can you try kill -PIPE $$ there? Anyway, I am not any expert here. But not rising SIGPIPE can yield pretty unexpected behavior, as $ yes | fold | true vs $ (trap "" PIPE; yes | fold | true) shows. (the first terminates, the second doesn't)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.