Bug 178926 - Change syslog facility
Summary: Change syslog facility
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-imapd
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-25 15:38 UTC by Ralf Ertzinger
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-03-01 15:23:17 UTC

Attachments (Terms of Use)

Description Ralf Ertzinger 2006-01-25 15:38:56 UTC
Description of problem:
The current spec file defines the log facility for cyrus imapd to be "mail",
instead of the standard "local6". While this is logical in a certain way, it is
impractical for filtering messages (using the standard syslog server). cyrus is
quite noisy, and significantly enlarges /var/log/messages. Neither the log level
nor the facility are run time configurable. I do not want to discard debug
messages at all since I still want mail.debug and other low levels from the mail
server software.

I propose to leave the log facility at local6. People who want combined logs can
do so by adding "local6.*" to the /var/log/messages line in syslog.conf. People
who want to filter the cyrus messages can redirect the wanted log levels to a
different file.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 John Dennis 2006-03-01 15:23:17 UTC
I understand the value of the proposed request, how it could be of benefit, and
how a workaround via changes to syslog.conf could emulate previous behavior.

However, to the best of my knowledge all of the mail packages in Fedora/RHEL log
to the mail facilty for obvious reasons. This would make cyrus imap an exception
that would likely confuse people. While local6 may be familar to long time cyrus
imap users I'm concerned local6 is sufficiently obtuse, many users will not make
the association and they will be perplexed by the inconsistency. I also believe
it's against packaging policy to edit another package's configuration file as
would be necessary to preserve the illusion of current behavior. For these
reasons I don't think the proposed change serves the fundamental goals of the
distribution and I'm inclined to recommend against it even though I see the
value in your proposal. Sound fair?

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