[tpop3d-discuss] tpop3d 1.4.2 : feature requests.

Chris Lightfoot chris at ex-parrot.com
Fri, 9 Aug 2002 13:14:08 +0100


On Fri, Aug 09, 2002 at 08:06:50AM -0400, Dave Baker wrote:
> On Fri, Aug 09, 2002 at 11:51:32AM +0100, Chris Lightfoot wrote:
> > > As it is, the "no-detach" and -d on the command line do not behave
> > > identically when I spawn tpop3d under daemontools.  specifically, if I
> > > just use no-detach then I end up with nothing going through my daemontools
> > > log processor.  Very odd.
> > 
> > Yeah. -d turns on the options to stay attached to the
> > controlling terminal, and to log to standard error in
> > addition to syslog. no-detach just tells it not to detach
> > from the controlling terminal. The log-stderr option is
> > separate.
> > 
> > Is a separate log-stdout option actually necessary, or can
> > you make do with tpop3d 2>&1 ?
> >
> 
> I'd have thought not, but I've put 2>&1 in a number of places and none of
> them entice it to log properly.

Does daemontools actually run things through the shell?
You might need to use

    /bin/sh -c "tpop3d -d 2>&1"

or similar.

> Even if this is some fat-finger trouble at my end, it would be nice for
> the same functionality to be available in the command line as it is in the
> config file ... so if -d talks to stdout I think it would be nice for that
> to also be available via log-stdout.

Nope, tpop3d presently never logs to stdout; the options
are syslog and stderr, or syslog only.

> > Is it necessary to prevent tpop3d from logging to syslog
> > when you're using daemontools?
> 
> Yes, since otherwise the logging output gets stored in two different
> places.  I don't want to ignore any mail.* syslog data since that may come
> from a non-tpop3d source, and kludging the config to change the syslog
> facility only to ignore it under a different name doesn't seem so hot
> either.
> 
> Perhaps have "syslog-facility: none" to do this? 

OK, that's easy enough and fairly sensible.

> > My thinking is that the `minimal logging' option should
> > give only the asterisked log lines for an entirely routine
> > connection. Thoughts?
> 
> Looks good.  I'd also like to see the text prefixes get dropped still
> (mailspool_new_from_file:, etc) - mostly so it helps prevent the lines from
> wrapping which I always finds helps log readability when I'm scanning them
> manually.  

Hmm.... The prefixes (prefices??) refer to the actual
functions in which the error is reported. I find this
useful for interpreting error reports.

> I haven't looked at that area of the code, but it may not be too hard to
> include a debug level that dictates what lines get logged, and within them
> what data items.  So, (default) might be just those *'d lines, -v
> (verbose) might be all of them, and -q (quiet) would trim down the log
> lines.  Multiple -v or -q could be experimented with if there was demand
> for more flexible logging output.

Well, tpop3d logs messages at levels

    LOG_ERR         203 cases
    LOG_WARNING      31
    LOG_INFO         33
    LOG_DEBUG        18

-- but of course the LOG_ERR cases only occur when
reporting actual errors (failure to log in, failure to
connect to database, failure to read mailbox). The problem
is that the granularity here may not be sufficiently fine
for your purposes.

(Do grep LOG_INFO *.c in the tpop3d source directory to
get an idea of the messages which are printed at this
level.)

-- 
``Suspecting the action was suspicious, the officer
  ordered both of them to raise their hands.''
  (from The Skagit Valley Herald)