The HUP and TERM signals work fine now. (with a ~ "Error: interrupted system call" message popping out, but they do work)
I wonder if is it a good idea to use penlogd in a heavy loaded site. Our site gets 200K hits in peak hours. If I balance between two or three machines, won't recvfrom leave the apache log mecanism waiting (too long)? Is 200K hits/hour (~60 per/second) too much for penlogd to log? I think it will be safer leaving on disk and merging them after.
> -----Mensagem original-----
> De: Ulric Eriksson [mailto:email@example.com]
> Enviada em: sábado, 11 de outubro de 2003 09:43
> Para: Diego Francisco de Gastal Morales
> Cc: firstname.lastname@example.org
> Assunto: Re: Penlogd not responding to TERM and HUP signals
> On Fri, 10 Oct 2003, Diego Francisco de Gastal Morales wrote:
> > The man page for penlogd says it will flush to the logfile if I kill
> > -HUP it (or -TERM and then exit). But that's not happening
> for me. It
> > does not write the log, nor exit.
> > It does respond to kill -9, but then (as expected) it does not write
> > the logfile.
> > It's a Freebsd 5.1 machine, pen 0.11.0. But the same occurs
> on my linux
> > machine.
> > Is it a known bug?
> It's not really a bug, it just doesn't work exactly as advertised. ;-)
> Since it's not safe for the signal handlers to do anything
> useful, they
> just set flags for things that will be done in the next pass
> through the
> main loop. But since penlogd sits blocking in recvfrom, that
> won't happen
> until it receives its next udp message. That doesn't matter for a busy
> site because the call won't block for long, but it's probably
> annoying if
> you just want to test flushing the logfile.
> One might wonder why recvfrom doesn't return when it is
> interrupted by the
> signal. Well, that's just how it is.
> I have uploaded a new penlogd.c to the usual place. It uses
> posix style
> signals, which allows this kind of legacy silliness to be
> disabled. If you
> try it out on your bsd system and it seems to work, we can
> just switch to
> that instead.
This archive was generated by hypermail 2.1.2 : Tue Oct 14 2003 - 01:09:21 CEST