Bug 154974

Summary: [RFE] Enhanced syslog capabilities
Product: Red Hat Enterprise Linux 4 Reporter: Joel Moxey <joel.moxey>
Component: sysklogdAssignee: Jason Vas Dias <jvdias>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: aleksey, riek, tao
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-15 23:01:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 155048, 185349    

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:
Always

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).