[syslog-ng]Urgent: Mangled messages in pipe() destinations in versions >1.5.8

[Balazs Scheidler]

On Sat, Dec 28, 2002 at 10:01:07AM +0300, Borzenkov Andrey wrote:
> [...]
> > What happens:
> 
> Another possibility is to push buffer back into output queue when write
> returns EAGAIN/EWOULDBLOCK. It has some potential of blocking output to a
> single destination, but then if destination cannot accept input anymore, it
> is probably broken anyway. Messages can be dropped on input side then (i.e.
> if queue is full, simply no new message is queued for this destination).

This was the indented behaviour and the patch I sent in my previous mail
does this.

> BTW it looks like syslog-ng makes writes in fixed 4096 buffer length. For
> pipes it is wrong - system guarantees atomic delivery of a single write up
> to PIPE_BUF; system is free to reorder parts of any single write with larger
> size. Portable way to query for PIPE_BUF on modern systems is to use
> (f)pathconf utility.

I don't understand you here. You mean that chunks of data written are
reordered, or if there is multiple write()-s to the same pipe then those may
get reordered?

I've found this comment by googling though (it is a release notes of
a rewritten pipe implementation for Linux):

----
* No single copy for exactly 4096 byte writes, only > PIPE_BUF.
Single copy (and thus blocking) such writes could trigger bugs in user
space apps that errorneously assume that a pipe write of PIPE_BUF bytes
after a successful poll(POLLOUT) doesn't block even if O_NONBLOCK is not
set. It's not defined in posix or susv2, but no unix version I tested
blocks in such writes.
----

BTW: syslog-ng puts the pipe fd in nonblocking mode, so if the chunk is too
large, write() should simply indicate that fewer bytes was written than
originally asked to.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1