[tpop3d-discuss] tpop3d 1.4.2 : feature requests.

Dave Baker dave at dsb3.com
Fri, 9 Aug 2002 08:06:50 -0400


--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 daemonto=
ols
> > log processor.  Very odd.
>=20
> 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.
>=20
> 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?=20


> > Secondly, a "brief logging" flag would be marvelous. =20
>=20
> Yeah, this is on the to do list too. At the moment, a log
> for a session looks something like
>=20
> * 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 sta=
le or corrupt data
> * tpop3d[4999]: mailspool_new_from_file: indexed mailspool /var/spool/mai=
l/... (... bytes) in ...s
> * tpop3d[4999]: connections_post_select: client [7]...(...): disconnected=
; .../... bytes read/written
>   tpop3d[4999]: authcontext_delete: finished session for `...' with mysql
>=20
> 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. =20

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

--=20

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


--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9U7BaDdRR1de8pV0RAprNAKC+fu8JYrmMxhHHCc1YOb/17tKyjQCfVCsc
eCEww+l+cZXePro4UWcVh1U=
=7XFJ
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--