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):
Steps to Reproduce:
Request For Enhancement
Internal RFE bug #155048 entered; will be considered for future releases.
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
BTW, the item (3) in this RFE is bug 20016 (which is still active).