From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Antill Subject: Re: event loss with dispatcher? Date: Thu, 08 Nov 2007 23:09:26 -0500 Message-ID: <1194581366.5537.15.camel@code.and.org> References: <1194563708.10377.13.camel@klausk.br.ibm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1303173666==" Return-path: Received: from mail.and.org (vpn-248-20.boston.redhat.com [10.13.248.20]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lA949SXC018688 for ; Thu, 8 Nov 2007 23:09:28 -0500 In-Reply-To: <1194563708.10377.13.camel@klausk.br.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: klausk@br.ibm.com Cc: Linux audit List-Id: linux-audit@redhat.com --===============1303173666== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EGrqkcDNL0BiP4WfKQ+G" --=-EGrqkcDNL0BiP4WfKQ+G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: >=20 > > On Thursday 08 November 2007 16:17:52 klausk@br.ibm.com wrote: > >> Any tips on how can I debug this further? > >=20 > > I'd put some syslog()'s in the main event loop of the dispatcher to se= e > > what is coming in and some in the output where its writing to the > > descriptor. > >=20 > > -Steve >=20 > Added a syslog() in the auditd code just before writev() to pipe, and=20 > another in audit dispatcher just after readv() from pipe (code attached=20 > in the end). I see every record coming out of the daemon, but some=20 > 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 =3D &e->hdr; vec[0].iov_len =3D sizeof(struct audit_dispatcher_header); /* Next payload */ vec[1].iov_base =3D &e->data; vec[1].iov_len =3D MAX_AUDIT_MESSAGE_LENGTH; do { rc =3D readv(fd, vec, 2); } while (rc < 0 && errno =3D=3D 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. --=20 James Antill --=-EGrqkcDNL0BiP4WfKQ+G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHM91y11eXTEMrxtQRAriBAKCvcXad6QYlF7XoTeV8Bd+Xe+38sgCfe2dR +kuub0oo4yRmtkHf+/8vcvw= =xrbd -----END PGP SIGNATURE----- --=-EGrqkcDNL0BiP4WfKQ+G-- --===============1303173666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1303173666==--