Bug 56581 - Broken Pipe errors.
Broken Pipe errors.
Product: Red Hat Linux
Classification: Retired
Component: fam (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Depends On:
  Show dependency treegraph
Reported: 2001-11-21 07:52 EST by Neil Darlow
Modified: 2008-05-01 11:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-28 19:04:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Neil Darlow 2001-11-21 07:52:03 EST
Description of Problem:
/var/log/messages reports Broken pipe errors

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

How Reproducible:
The error messages are there all the time

Steps to Reproduce:
1. default workstation/KDE/Development/Multimedia and games install

Actual Results:
/var/log/messages reports -
fd 4 write error: Broken pipe
fd 9 write error: Broken pipe
there are a lot of .famXXXX files in /tmp

Expected Results:

Additional Information:
Comment 1 Alexander Larsson 2001-11-21 11:01:16 EST
This would seem to indicate some fam client shutting down uncleanly. What apps
do you typically run?
Comment 2 Neil Darlow 2001-11-21 12:08:21 EST
The process id attached to the Broken pipe errors associates with:

xinetd[pid]: warning: can't get client address: Transport endpoint is not 

Comment 3 Alexander Larsson 2001-11-21 14:54:49 EST
I've seen that before. I've never really understood why it appears though. I
will have to research it in detail some day. It seems harmless though.
Comment 4 Neil Darlow 2001-11-22 03:15:25 EST
I think there might be a degree of urgency here. Consider:

Nov 20 13:41:36 ideal fam[10420]: fd 9 write error: Broken pipe
Nov 20 13:41:36 ideal last message repeated 609 times

I'd say that 609 loggings within a one second period is a lot of syslog 

That's got to hurt system performance.
Comment 5 Alexander Larsson 2001-11-26 15:31:02 EST
Ok. I researched the "can't get client address: Transport endpoint is not
connected" message, and it is harmless. It is more or less a bug in xinetd,
where it calls getpeername() on the wrong socket (the listening socket instead
of the client socket). This message will be printed by xinetd each time it
starts fam.

That is not the reason for your other message though. It seems some app connects
to fam, and then dies. Do you have any idea what app this is?

Comment 6 Alexander Larsson 2001-11-26 16:07:40 EST
I get this message when starting up KDE, so it's probably some KDE app exiting
without calling FAMClose() (or equivalently, not destroying the KDirWatch object).

I think it's mostly harmless. It seems to only happen on startup.

I'm reassigning this to kde-libs, which is clearly wrong, but there is no
general "kde" component, and i don't know which app to blame. I'm hoping bero
might look closer into this.

Comment 7 Neil Darlow 2001-11-26 16:18:15 EST
I'm running KDE also.

The fam errors don't appear to be related to other syslog messages 

On several occasions, too often to be considered coincidence, I do see this:

Nov 26 12:52:03 ideal xinetd[8904]: warning: can't get client address: 
Transport endpoint is not connected
Nov 26 12:52:17 ideal modprobe: modprobe: Can't locate module sound-slot-1
Nov 26 12:52:17 ideal modprobe: modprobe: Can't locate module sound-service-1-0
Nov 26 12:52:17 ideal modprobe: modprobe: Can't locate module sound-slot-1
Nov 26 12:52:18 ideal modprobe: modprobe: Can't locate module sound-service-1-0

I have a Soundblaster 16 Value card. ISA Plug and Play which I configured ok 
with sndconfig. The faulty application could be related to ArTs or somesuch.

There's precious little else to go on though. Even examining the timestamps of 
the /tmp/.famXXXX files doesn't tie-up with syslog entries to any degree.
Comment 8 Alexander Larsson 2001-11-26 17:20:59 EST
That's 14 seconds from something connection to fam to something trying to open
the sound device. Probably not the same app.
Comment 9 Alexander Larsson 2001-11-28 16:20:35 EST
I looked more into this, and is seems to actually be a fam problem.

The app cancels all the monitored objects, and then closes the connection, only
all the messages are queued up in the unix-domain socket, so the client closed
the connection before the server starts handling the cancel messages. And for
some reason fam tries to write to the client when handling the message, leading
to it getting broken pipe errors and printing warnings.

This is not an actual problem, but should be fixed. It's not highly priorotized
Comment 10 Hetz Ben Hamo 2001-11-28 16:28:14 EST
2 things:

1. It's not KDE specific as I've shawn to you both (alexl and bero)

2. Why it's not highly prioritize? it severly kills the performance if I get 
770 error messages...
Comment 11 Neil Darlow 2001-11-28 17:21:22 EST
Hetz is just reinforcing my performance-hit comment.

Remember, it's populating /tmp with .famXXXX files as well as clogging syslog.

I'd say this is also a quality issue. It reflects badly if not fixed.
Comment 12 Alexander Larsson 2001-11-28 19:04:23 EST
I will fix it. I just won't drop other important things and scramble to get this

Anyway, if someone thinks this is extremely important to get fixed today, I'm
accepting patches.
Comment 13 Alexander Larsson 2001-11-29 19:22:26 EST
Ok. This is fixed in 2.6.6-1, which will be availible in rawhide whenever the
buildsystem syncs to rawhide. I'll send the patch upstream.
Comment 14 Hetz Ben Hamo 2001-11-29 19:34:59 EST
Umm, that will be a bit of a problem since RH 8.0 won't be backward compatible 
with RH 7.2 (gcc, glibc, etc...)

Could you put somewhere an SRPM and I'll rebuild it on 7.2? I'll be happy to 
provide the RPM's back ;)

Comment 15 Alexander Larsson 2001-11-29 21:56:16 EST
I've build 7.2 packages too. I will push them tomorrow.
Comment 16 Alexander Larsson 2001-11-30 11:05:06 EST
i386 rpms + SRPMS availible at:


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