Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#8 Control flushing per output

closed-accepted
nobody
None
5
2009-03-15
2009-01-30
No

I would like to configure flushing on a per output basis, so that I can enable it for low volume critical messages, but disable it for high-volume debug messages. Looking at the code, the thing doesn't look too hard, so I've attached a patch that should do this. The idea is to keep the current command line / SIGUSR{1,2} controlled behaviour the global default, but allow overriding for individual outputs. This allows for a wide spectrum of applications, from full backwards compatible behaviour without any fixed flushing rules to fully specified flushing behaviour for every single output, except maybe one you are currently debugging and want to switch using signals.

The patch currentrly expects "flush = 0" or "flush = 1", but as it uses atoi it doesn't enforce this. A string comparison might make sense, but this should be used for break and others as well, and therefore put into a separate function and a separate changeset, I think.

I decided to use an enum for the different configuration values, in order to maximize readability. In some cases inequalities might have helped to keep things shorter, but I don't believe it's worth it to risk maintainability for those few instructions.

I also added a call to flush all logs when SIGUSR1 is received, so that buffered messages will be flushed out immediately, not only when the next message arrived. I factored this "flush all buffers" code into a reusable function. The previous logic to only flush at exit when in asynchronous mode was probably broken, as there might have been unflushed messages from before the latest switch. With the addition to the sigusr1 handler, this should be solved, but with the addition of fine-grained flushing control, the logic would become much more complicated. In the end, I decided to simply flush all buffers, and expect that to be fairly cheap in case they already were flushed.

I added a paragrapg to the metalog.conf(5) man page, and also a SIGNALS section to the metalog(8) man page.

Discussion

  • 1st revision of "flush"

     
    Attachments
  • Mike Frysinger
    Mike Frysinger
    2009-03-15

    • status: open --> closed-accepted
     
  • Mike Frysinger
    Mike Frysinger
    2009-03-15

    thanks, added to svn