Re: [tpop3d-discuss] tpop3d 1.4.2 : feature requests.

[Dave Baker]

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.

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.


> 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? 


> > Secondly, a "brief logging" flag would be marvelous.  
> 
> Yeah, this is on the to do list too. At the moment, a log
> for a session looks something like
> 
> * tpop3d[26306]: listeners_post_select: client [7].../...: connected
>   tpop3d[26306]: authcontext_new_user_pass: began session for `...' with 
> mysql; uid 558, gid 558
> * tpop3d[26306]: fork_child: [7]...(...): successfully authenticated with 
> mysql
>   tpop3d[26306]: fork_child: new child is PID 4999
>   tpop3d[4999]: mailspool_load_index(...): index exists, but has some stale 
> or corrupt data
> * tpop3d[4999]: mailspool_new_from_file: indexed mailspool 
> /var/spool/mail/... (... bytes) in ...s
> * tpop3d[4999]: connections_post_select: client [7]...(...): disconnected; 
> .../... bytes read/written
>   tpop3d[4999]: authcontext_delete: finished session for `...' with mysql
> 
> 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.  

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.

Dave

-- 

- Dave Baker  :  address@hidden  :  address@hidden  :  http://dsb3.com/ -
GnuPG:  1024D/D7BCA55D / 09CD D148 57DE 711E 6708  B772 0DD4 51D5 D7BC A55D

pgpE7x0TO0aBW.pgp
Description: PGP signature