Bug 1902021
| Summary: | postinstall scripts print scary "find: Broken pipe" messages | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | microcode_ctl | Assignee: | Eugene Syromiatnikov <esyr> |
| Status: | CLOSED ERRATA | QA Contact: | Jeff Bastian <jbastian> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.3 | CC: | esyr, fadamo, jbastian, rvr, skozina |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | microcode_ctl-20201112-2.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-18 14:54:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
See also bug 1781365; I wonder now if the efficiency gains of grep -q are worth all the hassle as well as hiding other possible find-induced error messages. (In reply to Eugene Syromiatnikov from comment #1) > See also bug 1781365 Or, more specifically, bug 1781332. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (microcode_ctl bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:1613 |
Description of problem: When updating or reinstalling "microcode_ctl", the following stderr messages are often seen, which can confuse customers: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Running scriptlet: microcode_ctl-4:20200609-2.20201027.1.el8_3.x86_64 1/2 /usr/bin/find: ‘standard output’: Broken pipe /usr/bin/find: write error /usr/bin/find: ‘standard output’: Broken pipe /usr/bin/find: write error ... -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The issue is due to having the following piece of code in /usr/libexec/microcode_ctl/check_caveats: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 631 { /usr/bin/find "$MC_CAVEATS_DATA_DIR/$cfg" \ 632 -path "$MC_CAVEATS_DATA_DIR/$cfg/$p" -print0; 633 /bin/true; } \ 634 | /bin/grep -zFxq "$cpu_mc_path" \ 635 || continue -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- From above, a "find" command is piped to a "grep -q" command. Due to using "grep -q", the command will exit as soon as there is a match of the pattern, not waiting for reading the rest of the content received from standard input (i.e. the "find" command output). Due to this, when "find" sends more output, the write() syscall returns with EPIPE error and makes "find" print the error message. I know it's harmless but this kind of messages should be avoided. The solution here is likely to redirect stderr for "find" to /dev/null. Version-Release number of selected component (if applicable): microcode_ctl-20200609-2.20201027.1.el8_3.x86_64 How reproducible: 90% of the time on a system with more than 1 kernel installed Steps to Reproduce: 1. "yum -y reinstall microcode_ctl" Expected results: No "find" stderr messages Additional info: The reason for this is %postinstall scriptlet executes with SIGPIPE ignored, as seen in the strace excerpt below: We have "find" (PID 1893564), forked by PID 1893562, forked by PID 1893547, forked by PID 1890437, the latter ignoring SIGPIPE: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 1893564 08:09:58.994098 execve("/usr/bin/find", ["/usr/bin/find", "/usr/share/microcode_ctl/ucode_with_caveats/intel", "-path", "/usr/share/microcode_ctl/ucode_with_caveats/intel/intel-ucode/*", "-print0"], ... 1893547 08:09:58.983373 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb051fc6a10) = 1893562 <0.000103> 1890437 08:09:58.849811 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa283820a10) = 1893547 <0.000088> 1890437 08:09:21.144397 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fa459938880}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa45a460b20}, 8) = 0 <0.000015> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- PID 1890437 being the shell script executing the %postinstall script: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 1890437 08:09:21.148698 execve("/bin/sh", ["/bin/sh", "/var/tmp/rpm-tmp.pphSgk", "2"], ... -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------