On Thu, 2007-11-08 at 18:15 -0500, Klaus Heinrich Kiwi wrote:
> On Thu, 08 Nov 2007 16:55:22 -0500, Steve Grubb wrote:
> 
> > On Thursday 08 November 2007 16:17:52 klausk@br.ibm.com wrote:
> >> Any tips on how can I debug this further?
> > 
> > I'd put some syslog()'s  in the main event loop of the dispatcher to see
> > what is coming in and some in the output where its writing to the
> > descriptor.
> > 
> > -Steve
> 
> Added a syslog() in the auditd code just before writev() to pipe, and 
> another in audit dispatcher just after readv() from pipe (code attached 
> in the end). I see every record coming out of the daemon, but some 
> records are lost at the dispatcher input:
[...]
> Still don't have a clue of what's going on. here's the patch used:

 Byte stream I/O 101. The "readv" side is:

         /* Get header first. it is fixed size */
        vec[0].iov_base = &e->hdr;
        vec[0].iov_len = sizeof(struct audit_dispatcher_header);

        /* Next payload */
        vec[1].iov_base = &e->data;
        vec[1].iov_len = MAX_AUDIT_MESSAGE_LENGTH;

        do {
                rc = readv(fd, vec, 2);
        } while (rc < 0 && errno == EINTR);
        if (rc > 0) {
                enqueue(e);
        }

...where enqueue() assumes that a single "message" and _only_ a single
"message" has been read, SOCK_STREAM makes no such guarantee. As more
messages are produced from auditd it becomes more likely the OS will
merge multiple "messages".
 The writev() sides of audispd are broken in a similar way, although
that might be more obvious as it will just start corrupting the byte
stream.

-- 
James Antill <jantill@redhat.com>