Talk:Syslog/Archive 1
 | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
A liitle more detail, please.
How about mentioning such concepts as Facility and Level, perhaps listing the standard levels (Debug, Information, Notice, Notice, Warning, Error, Critical, Alert, Emergency).
For now, this article reads more like a stub than an entry on a major internet standard. —Preceding unsigned comment added by BenStrauss (talk • contribs) 20:16, 9 June 2008 (UTC)
- Just edited the article to change the word "level" into "severity". It's not called level. Check RFC 5424. It predominantly talks about severity, and not level. Granted, the old RFC did mention level a few more times, calling it "security levels" on occassion. But not anymore. Manadar (talk) 09:32, 29 December 2011 (UTC)
- Manadar's edit is good: the term "severity" should be used. But the terms "severity", "facility", and "priority" are field names; the terms "level" and "value" refer to the value of a field. This is true both in the UNIX standard and in RFC 5424. Contrary to Manadar's statement, RFC 5424 refers to the "severity level" at least once. The UNIX standard refers to the "severity", the "severity level", and the "severity-level". So yes, the word "severity" should be used, but no, avoiding the word "level" is not necessary (and may even create confusion). — Preceding unsigned comment added by Metaed (talk • contribs) 16:55, 29 December 2011 (UTC)
Severity levels: description
The general description in the Severity level needs revision. syslog does not define that CRIT indicates a " failure in a secondary system", nor "within a given time" nor who should be notified.
I will wait a while in case someone should like to respond before I revise this. DGerman (talk) 17:00, 1 September 2013 (UTC)
- Well, the Wikipedia policy is "be bold". So I guess you can just do it, and if someone disagrees, they will correct. Thanks for your participation!
#!/bin/DokReggar -talk07:09, 2 September 2013 (UTC)
- @DGerman, my reading of RFC 5424 agrees with your oberservation, I support your proposed changes. Ben Aveling 10:28, 2 September 2013 (UTC)
Directing messages
Specific configuration may permit directing messages to various devices is this a feature of syslog or the syslog daemon? DGerman (talk) 21:23, 26 May 2015 (UTC)
rework needed
This article has become seriously convoluted, missing important concepts and including excessive detail.
I will attempt to rework it. Unfortunately I will need to do this piecemeal.
I welcome you comments, but please wait several days in case I (or someone else) makes intermediate changes.
I
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am strongly in doubt if all the product/vendor links in the "implementation" section are really helpful. Anyhow, I've tried to complete it for now and brush it up, but I'd recommend to remove it altogether. Rgerhards 14:00, 26 January 2006 (UTC)
what happened in 2005
The article currently says "A formal specification and standardiziation of message content and transport layer mechanisms is scheduled for 2005." What was the outcome of the scheduled 2005 discussion?
See http://www.ietf.org/html.charters/syslog-charter.html for the latest news on syslog standardization
What about local syslog?
Is there a reason this article is entirely about the network protocol? syslog is on every unix machine and most of them neither send nor accept log messages over the network. The typical syslog configuration just writes everything to a few local files. If asked to summarize syslog, I'd say it's a service for collecting log messages from many sources and routing them in a configurable manner to various destinations. The sources and destinations can be remote hosts but usually aren't. --Tcsetattr 06:34, 31 January 2007 (UTC)
I edit this entry to reflect this. DGerman (talk) 19:40, 2 April 2010 (UTC)
Implementations section
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Products are creeping in here that are related to syslog but do not actually implement it. Perhaps a separate section is more appropriate for these, or elimination of the non-syslog products. —Preceding unsigned comment added by 70.230.73.42 (talk) 16:26, 21 August 2008 (UTC)