views:

150

answers:

2
+1  Q: 

Reason for SIGPIPE

I have an application running on Linux, catching signals and reporting them to syslog.

This application frequently reports SIGPIPE events with no apparent reasons

The application is running in the background, as daemon. The signals occur at idle times with no apparent network/socket connections. The application frequently reads from and writes to disk and DVB cards (via the kernel DVB drivers).

I would like to find out the reason for the SIGPIPEs. Any means for tracing the signal source?

Edit: I have added this to the code:

 stdin  = freopen("/dev/null", "r", stdin);
 stdout = freopen("/tmp/vdr_stdout", "w", stdout);
 stderr = freopen("/tmp/vdr_stderr", "w", stderr);

Still get the SIGPIPEs.

A: 

Does your daemon close input and output?:

fclose (stdin);
fclose (stdout);
fclose (stderr);
wallyk
It does not. I just found out that there are use cases for keeping these open. The initialization part has even code to attach stdin, stdout and stderr to a new controlling terminal using freopen() (I don't use that)
Bernd
+1  A: 

On POSIX-compliant platforms, SIGPIPE is the signal sent to a process when it attempts to write to a pipe without a process connected to the other end.

Since you are referring to a daemon context, maybe the STD* are closed and an attempt to read/write on those is performed.... a debug/progress report printf maybe?

jldupont
Yup, there are fprintf()s in one module. I'll test with binding stdin, stderr and stdout to a temp file in order to check if the SIGPIPEs go away. But that needs a moment of downtime...
Bernd
Opening them to `/dev/null` is typical.
ephemient