Hi Robert, I don't know you other than by your contributions here which I appreciate deeply. The patch I submitted had two real components. One component was the logging plugins, the other were the changes necessary to support using logging hooks.
The plugins I included were simple, non-complex and straight forward enough to serve as a proof of concept. The changes to Qpsmtpd.pm and qpsmtpd-forkserver are a bit less trivial. If we could focus on these changes rather than the plugins at this point, I think we'd be better served. The problem I'm most concerned about is that while using run_hooks() to log some event, it also logs what it's doing. I had to modify the log() and run_hooks() to remember when I'm logging a real event and not fall into recursion of logging a log event of a log event of a log event of a ... of a real event. If you're okay with all the changes but only have an issue with the syslog plugin, I'm happy to forge forward and implement all bells and whistles one might expect in a syslog plugin. I think there's a little room for cleaning up the run_hooks() function and taking the binary crib variable out of the log() function. I haven't spent a lot of time studying what the best way to handle the logging hook. Perhaps the actual dispatch could be in a run_hooks_nolog() or add a arg to run_hooks() that includes do_logging => no or something. I don't think that me mucking about in run_hooks() really serves anyone's interest, but someone with an experience eye in that function could probably quickly identify the the right thing. If you could help with this particular aspect and get the changes committed, I'd be indebted and I'd then be emotionally free to build the syslog plugin to end all syslog plugins. Thanks, peter On 12/5/04 12:45 AM, "Robert Spier" <[EMAIL PROTECTED]> wrote: >> I'm sure my simple logging/syslog plugin could be enhanced. In the case of >> syslog, this cutoff can be ultimately controlled in /etc/syslog.conf. >> Perhaps the lower level events don't get written to disk, or maybe they do >> but get rolled more often. Maybe some are written to a pipe from syslog. >> It's all in the config. > > Yeah, but if we're going to do it, we might as well do it right and > provide _consistent_ flexibility. > >>> How does config/loglevel work with your patch? >> >> Ignored. > > Then lets remove it. If we're going to go to pluggable and > configurable logging, lets do it all the way. > >>> Also, you need a way to provide a syslog log facility. >> >> Uhh, no. 'mail' seems pretty logical to me. > > I have three different instances of qpsmtpd running on some of my > boxes. What if I want one to log to local2 and another to local3? > > There's no reason _not_ to make these things configurable. > > -R >
