Named pipe behavior in Linux

Hi All !

I try to collect importent events from syslog and in my
syslog conf, there is something like this:

*.*  |/logs/ipes/SLpipe1

I have a program, which opens this pipe and reads the messages from it.

But how this pipe works ? Where can I probably read something about the details, like: Is the pipe buffered, what happens to the sender, if the pipereader dies, is it possibly to connect again, how is the buffersize configured, etc.

Any help would be really great!

Thanks so far and
best regards,

++mabra

Syslog needs a real file, or the udp packets flowing to it may be discarded.

A named pipe is a sort of clue to the O/S to pair up open-for-write and open-for-read calls and pipe them together, so if one appears and not the other, things stall or error out. If there is a service app in a loop opening the pipe for read, forking a child or thread to read it, process the input and close it, it accomodates all client writers:

$ while :
 do
  ( ksh -c '
   while read l
    do
     echo "$$: $l"
    done
   '& )<p
 done &
[1]     4097
$ date >p                                                                     
$ 4098: Fri Jan  4 09:02:57 EST 2013
$ date >p
4101: Fri Jan  4 09:03:00 EST 2013
$ echo hi >p
$ 4103: hi
ls -l p
prw-r--r--   1 myid        mygrp            0 Jan  4 09:03 p
$ 

Note that the outer loop stalls trying to open the pipe until a write open on the pipe occurs. It works either way, but seems to be unidirectional.

$ while :
do
 ksh -c 'echo $$:`date`' >p
done&
[1]     907
$ cat <p
908:Fri Jan 4 11:11:38 EST 2013
$ cat <p
944:Fri Jan 4 11:11:44 EST 2013
$ cat <p
960:Fri Jan 4 11:11:46 EST 2013
$ 

Hi ! Many thanks for your reply !

I believe, that I understand the basics so far.

I let rsyslog write to a pipe and this works well. As long as my pipe reader, a program written in C# from the Mono framework, is running, there are no problems. From test, I saw, that rsyslog continues sending it's messages to the pipe, after my program dis-connects and then re-connects.

Would be great to configure the buffer though.

Best regards,

++mabra

It's still better practice to log it first, even if you want to filter or compress it later, so event alerts are not lost.