Bug 154974 - [RFE] Enhanced syslog capabilities
[RFE] Enhanced syslog capabilities
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sysklogd (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brian Brock
: FutureFeature
Depends On:
Blocks: 155048 185349
  Show dependency treegraph
 
Reported: 2005-04-15 04:00 EDT by Joel Moxey
Modified: 2008-08-01 22:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-15 18:01:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joel Moxey 2005-04-15 04:00:17 EDT
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 16:41:16 EDT
Internal RFE bug #155048 entered; will be considered for future releases.
Comment 3 Jason Vas Dias 2005-06-09 12:49:02 EDT
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 15:49:04 EDT
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.