Bug 14781
| Summary: | Broken pipe | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | paulh |
| Component: | bash | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-09-26 01:55:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
See bug 8266 for more information and a possible work-around patch for bash. THis error has disappeared since RedHat 7.0 on my nightly builds. Maybe this bug should be closed The bug should not be closed, as it hasn't been fixed in RHL 6.2. The reason it appears fixed in RHL 7.x is (I think) that these systems use bash2 as the default shell. If bash1 is still included in these systems, it probably still has this bug. Anyway, even if the bug should be fixed in RHL 7.x's bash1, it should also be fixed in RHL 6.2, as RH still support that release. Hi Red Hat Support, I have a customer on RHL6.2 and experiencing the report problem with bash as follows "Can't reopen pipe to command substitution" and when can I expect this to be fixed in RHL6.2?? If no fix then what suggestions do I provide to my customer?? DD. (This is not Red Hat Support.) This bug is fixed in the current release; closing. |
Since RH 4, we have been plagued by an errors usually from the shell : Cannot reopen pipe and the shell script fails. Netscape sometimes also fails to start with error about a broken pipe. I am unable to find any reference to similar problems in the various online resources. Also, this seems to occur at random on a variety of machines ranging from Embedded motherboards to 733MHz PIII under a variety of loads. I need some assistance on where to look in the kernel sources to track this problem.