Bug 60125 - log file clutter
Summary: log file clutter
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: imap
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-20 17:26 UTC by Jeff Norden
Modified: 2007-04-18 16:40 UTC (History)
0 users

Clone Of:
Last Closed: 2002-02-20 17:26:36 UTC

Attachments (Terms of Use)

Description Jeff Norden 2002-02-20 17:26:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.12 i686)

Description of problem:
I agree that UW-imap is not an ideal software pkg, but there doesn't
seem to be a better alternative that uses standard mbox files.  My only real
complaint is that when user-clients check for mail every few minutes, the
imap entries wind up flooding the standard log files.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install imap-xxx.rpm
2. Have some folks point outlook-express at your server.
3. Try to find the 'non-imap' messages in /var/log/secure and
   /var/log/maillog :-)

Additional info:

Cleaning up /var/log/secure is easy - just add the line

  log_type = FILE /var/log/imap.log

to the appropriate files in /etc/xinetd.d/


/var/log/maillog is more troublesome.  One possible fix is to hack imapd to
change its syslog facility from LOG_MAIL to, eg, LOG_LOCAL1, and then use
/etc/syslogd.conf to re-direct the messages.  But this fix would not really
be an appropriate for a distribution (what if every package wanted to use

A better fix is to have imapd, etc, accept an optional command-line argument
giving the name of a log file, and then have messages go directly to the
file (and if no logfile is given, continue to use syslog with LOG_MAIL).
Then the clutter can be eliminated by also adding

  server_args = --logfile=/var/log/imap.log

to the appropriate /etc/xinetd.d/ files.


I've implemented the above change in about 90 lines of code.  I'm planning
to send it upstream to Mark Crispin at UW.  But my code assumes that libc
has working getopts_long() and strftime() functions, so he may be less than
enthusiastic.  Please let me know if you might be interested in including
this fix in the redhat rpm.  If so, I'll clean things up a bit (and add
patches for the man pages and spec file) and submit it as an attachment.

-Jeff Norden

Comment 1 Mike A. Harris 2002-02-21 07:09:48 UTC
The best solution I can think of is to use logrotate to compress
and rotate the logs at a frequency that is useful.  Alternatively,
run a cron job to filter the logs for what is wanted/not wanted.

Changing the LOG facility to LOG_LOCAL1 would violate standard expected
behaviour, as well as possibly violating published standards I would
presume.  It would also fork our imap package from the upstream
maintainer's version, and I am not willing to do that.

This proposed change, while it may solve the problem for you, is not
a proper solution.  The problem isn't the imap server IMHO, but rather
the logging services themselves.  syslog in particular.

I doubt Mark Crispin will change the log level as you suggest either
because by definition LOCAL* log levels are for the local system
administrators usage, and are not to be used by system supplied
packages.  I just fixed a bug in xfs from using LOCAL0, and if upstream
were to incorporate this change, I would have to remove it on our end.

Sorry, but a proper solution to this needs to be found that does not
interefere with standards, nor expected behaviour.  Again, I suggest
using a log parsing script via cron and/or logrotate.

Comment 2 Jeff Norden 2002-02-21 16:34:21 UTC
Sorry, I guess the end of my post wasn't quite clear.  I fully agree that
using a LOCALn log level is *not* an appropriate fix (except as a local

What I've written is a patch that *allows* impad to send messages directly
to a file, much the same as specifying 'log_type = FILE' to xinetd.
Starting the server with 'impad --logfile=/var/log/imap.log' causes all
messages to go directly to imap.log, and not through the syslog routines at
all.  Starting the server without the logfile option gives the old behavior
of using syslog with the LOG_MAIL facility.  So there should be no problem
with standards or compatibility.  Please let me know if you'd like me to clean
up and submit the patch.

I also agree that the root of the problem lies in the current implementation
of syslog altogether.  It would be nice to be able to specify in syslog.conf
that all messages from a specific daemon should go to a specific file.  But
that won't be easy to do.  It would require changing *both* syslogd *and*
the syslog/openlog routines in glibc, because the current syslog subroutine
only passes the priority/facility information to syslogd.  There would be
two serious obstacles to deal with: (1) backward compatibility with the BSD
syslog standard, and (2) performance - it would probably be bad to make
syslogd parse and lookup an identity string for every logged message.

Note You need to log in before you can comment on or make changes to this bug.