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: Always Steps to Reproduce: Request For Enhancement Additional info:
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 syslogd's reliability.
BTW, the item (3) in this RFE is bug 20016 (which is still active).