Re: logd vs. Polygraph

From: Robert Collins <robert.collins@dont-contact.us>
Date: 23 Aug 2001 08:22:51 +1000

On 22 Aug 2001 22:39:47 +0200, Henrik Nordstrom wrote:
> Robert Collins wrote:
>
> > I call
> > lf->logfd = lf->ipccomm.pwfd;
> > commUnsetNonBlocking(lf->logfd);
> > where lf->logfd is the fd that logfileWrite calls will use to send data
> > to the log. That should set it NonBlocking yes?

I typed badly there.. I meant should set it to Block IO. doh.

> This should clear the non-blocking flags, reverting to blocking I/O mode.
>
> > I've added an assert to the write function, to die if bytes_read
> > increases on the logd's stdin fd. I can't commit that until sourceforge
> > come back up though.
>
> ???

Sourceforge had a 6 hour planned outage of CVS services.
 
> What you should check is that the amount of bytes written is the same as the
> requested amount. Reading is irrelevant.

Squid keeps the read end of the pipe open, so it can pass it to
reincarnated logd's. This is just to be absolutely sure that no reading
by squid is done. I was assuming that the data loss was occuring because
the log daemon wasn't getting all the data. (We're talking about
access.log in this case).

> > A related question: should we flush() the pipe/socket before we kill the
> > old helper? (If we don't, when we reuse the pipe/socket, I think we
> > could collide with in-pipe/socket data?).
>
> Are you using stdio? If so you SHOULD fflush() before killing to make sure all
> log data has been sent over the pipe. But the log FILE should at most be set for
> line buffering as there may be more than one process writing.

Thanks.

The detail: for access.log, _only_ logd writes to the logfile.
Everything else writes to the logd pipe. For cache.log, I left the
debug() macro writing directly to the log file, and just had the spawned
helpers writing to the logd pipe.

> --
> Henrik
>
>
Received on Wed Aug 22 2001 - 16:22:37 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:15 MST