Bug 154974 - [RFE] Enhanced syslog capabilities
Summary: [RFE] Enhanced syslog capabilities
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sysklogd
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact: Brian Brock
Depends On:
Blocks: 155048 185349
TreeView+ depends on / blocked
Reported: 2005-04-15 08:00 UTC by Joel Moxey
Modified: 2008-08-02 02:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2006-02-15 23:01:12 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Joel Moxey 2005-04-15 08:00:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

Description of problem:
Need a syslog daemon that has much more flexibility than the current daemon that comes as standard - functionality such as:

1) Write the log entry to a local MySQL database (columns: host, facility, priority etc...)
2) Write the log entry to a remote MySQL database (columns: host, facility, priority etc...)
3) Write a log entry into specific directories based on host, for example: a syslog server receives a messages from host1, and then writes the entry in /syslog/host1/messages

i.e. Like syslog-ng, but with support organisation.

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

How reproducible:

Steps to Reproduce:
Request For Enhancement

Additional info:

Comment 1 Suzanne Hillman 2005-04-15 20:41:16 UTC
Internal RFE bug #155048 entered; will be considered for future releases.

Comment 3 Jason Vas Dias 2005-06-09 16:49:02 UTC
It is on principle a bad idea to have syslogd dependant on another
process such as a database server for handling log messages. 
This introduces the possibility that either:
   A) log messages may get dropped 
or B) syslogd may end up hanging for a log message to be processed,
      which in turn can hang the whole system.
If you do not care about these vulnerabilities, you are free to run
syslog-ng, or even with the standard syslogd, you can have it write
to a pipe or socket log destination which is read by a process that
will write the messages to a database; but by the nature of IPC, this
can never be as reliable as writing to the filesystem (syslogd will
drop messages sent to a pipe whose buffer is full, as it should).

I'll commit to developing some such syslogd helper processes for
RHEL-5, that can read messages from a pipe and can invoke scripts 
to handle them and can do regexp filtering / database archival /
whatever with them. But their use should never be the default, 
because any such dependancy on another process inherently weakens
syslogd's reliability.


Comment 6 Aleksey Nogin 2006-08-07 19:49:04 UTC
BTW, the item (3) in this RFE is bug 20016 (which is still active).

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