Re: event loss with dispatcher?
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(a)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(a)redhat.com>
Attachments:
- signature.asc (application/pgp-signature — 189 bytes)