FAQ
We have a local version of Go that we've been maintaining with a
modification to log/syslog that brings it into compliance with RFC3164 by
adding the timestamp and hostname into the syslog messages and by
augmenting the prefix with the [pid]
(see https://code.google.com/r/dane-go/source/detail?r=c183c1a73c11c9d78d70264f8d150979b0525ca9&name=1.0.3-syslog)

Is this something folks would like submitted as a patch?

John.

--

Search Discussions

  • Minux at Nov 15, 2012 at 6:16 pm

    On Fri, Nov 16, 2012 at 1:56 AM, John Graham-Cumming wrote:

    We have a local version of Go that we've been maintaining with a
    modification to log/syslog that brings it into compliance with RFC3164 by
    adding the timestamp and hostname into the syslog messages and by
    augmenting the prefix with the [pid] (see
    https://code.google.com/r/dane-go/source/detail?r=c183c1a73c11c9d78d70264f8d150979b0525ca9&name=1.0.3-syslog
    )

    Is this something folks would like submitted as a patch?
    I'd recommend you provide it as a separate go-gettable package.

    --
  • John Graham-Cumming at Nov 15, 2012 at 6:57 pm

    On Thursday, November 15, 2012 6:17:06 PM UTC, minux wrote:

    I'd recommend you provide it as a separate go-gettable package.
    Can you explain the rationale for that? As it is the log/syslog package is
    not RFC compliant.

    John.


    --
  • Dustin Sallings at Nov 15, 2012 at 10:04 pm
    John Graham-Cumming <jgc@cloudflare.com>
    writes:
    On Thursday, November 15, 2012 6:17:06 PM UTC, minux wrote:

    I'd recommend you provide it as a separate go-gettable package.


    Can you explain the rationale for that? As it is the log/syslog
    package is not RFC compliant.
    One thing is that existing applications could immediately use your
    implementation. If something's badly broken, fixing it for everyone
    would be great. (I use log/syslog heavily)

    --
    dustin

    --
  • Russ Cox at Nov 25, 2012 at 7:36 pm
    Please feel free to send a fix to make log/syslog RFC 3164-compliant.
    We're not actively trying to avoid standard behavior there; it was an
    oversight.

    Thanks.
    Russ

    --
  • Jed Smith at Nov 26, 2012 at 1:45 am
    I'm glad people are paying attention to log/syslog, as that one's kind of
    been a thorn for me lately. The one omission that remains even after your
    patch is awareness of facility. As it stands, log/syslog writes the
    priority given verbatim, like so (for a Debug message):

    <7>...


    The problem with this is that facility is being implied as facility 0,
    which is assigned to the kernel. As a result, all syslog messages emitted
    by a Go program will be treated by a receiving syslogd as kernel messages.
    If they end up in a "messages" file of some kind, that means the
    distribution is configured to make kernel messages go to the "messages"
    file as well. In my case, I have a unique syslog configuration due to
    centralization, and I noticed that all Go programs were speaking as kernel
    and that I was not handling them appropriately as a result.

    At the very least, log/syslog should emit as facility 1, which is "user".
    However, I also think that should become a default which can be changed at
    run time, since I make heavy use of the local facilities (local0 through
    local7) and I'm sure others do as well. Since that's an API addition,
    everybody wins from the new default being "user", and those that care can
    add code to pick a different facility, like "mail" or "local0".

    This is a trivial patch so I might put it together if I get some time, but
    I'd definitely hope you'd include it if your patch is headed for the
    standard library.

    --
  • John Graham-Cumming at Nov 26, 2012 at 10:28 am

    On Mon, Nov 26, 2012 at 12:55 AM, Jed Smith wrote:
    The problem with this is that facility is being implied as facility 0, which
    is assigned to the kernel. As a result, all syslog messages emitted by a Go
    program will be treated by a receiving syslogd as kernel messages. If they
    end up in a "messages" file of some kind, that means the distribution is
    configured to make kernel messages go to the "messages" file as well. In my
    case, I have a unique syslog configuration due to centralization, and I
    noticed that all Go programs were speaking as kernel and that I was not
    handling them appropriately as a result.
    The real problem here is that what syslog.go calls a Priority is
    actually a Severity and it doesn't have any notion of the Facility.
    RFC5424 says Priority = Facility * 8 + Severity. The code currently
    just takes the 'bogus' Priority value and uses it (actually a
    Severity) as Priority. As you say this is that same as Facility == 0
    (which is kernel).

    To fix this means introducing a backwards incompatibility because the
    current implementation is simply wrong. I am going to submit a CL that
    fixes this, but it is going to break existing programs because I don't
    think there's any way round the fact that this package's notion of
    Priority simply doesn't match RFC5424 and trying to keep compatibility
    while fixing this problem will result in an ugly wart.

    John.

    --
  • Jed Smith at Nov 26, 2012 at 12:08 pm

    On Mon, Nov 26, 2012 at 2:28 AM, John Graham-Cumming wrote:
    To fix this means introducing a backwards incompatibility because the
    current implementation is simply wrong. I am going to submit a CL that
    fixes this, but it is going to break existing programs because I don't
    think there's any way round the fact that this package's notion of
    Priority simply doesn't match RFC5424 and trying to keep compatibility
    while fixing this problem will result in an ugly wart.
    (Sorry for the dupe, John, back to personal Gmail with "default reply
    all" turned off...)

    It doesn't have to be an incompatibility. There's two fixes that work
    and remain compatibile but that change behavior quietly:

    1. Base the Priority constants at 8 instead of 0, to emit as "user".

    2. Add a Facility field to Writer; unfortunately, the null value is
    "kernel" again. Since client code is not instantiating Writer
    directly, Dial() can simply set Facility = 1 then leave it up to
    client code to alter the default if desired.

    The Dial() and New() APIs are tricky, agreed, and we're likely stuck
    with them for a while.

    --
    Jed Smith
    jed@jedsmith.org

    --
  • John Graham-Cumming at Nov 26, 2012 at 1:39 pm

    On Mon, Nov 26, 2012 at 12:08 PM, Jed Smith wrote:
    It doesn't have to be an incompatibility. There's two fixes that work
    and remain compatibile but that change behavior quietly:

    1. Base the Priority constants at 8 instead of 0, to emit as "user".
    Yes, but that's kind of an ugly hack to make it just emit as user. I
    honestly think this is one of those cases where it's necessary to say
    'we made a mistake with the initial API; let's change it'. I realize
    that compatibility is important in Go but I question how many people
    are using the syslog package at the current time given that it doesn't
    correctly handle the priority/severity/facility and omits the hostname
    and timestamp. Anyone who is is probably having to do some ugly hack
    like run a second syslogd so that they can separate out these bogus
    'kernel' messages and they are having to manually add the hostname and
    timestamp to the message.

    I have submitted a CL which I think corrects the errors in the syslog
    implementation at the cost of incompatibility:
    http://codereview.appspot.com/6782118

    John.

    --
  • Jed Smith at Nov 26, 2012 at 5:26 pm

    On Mon, Nov 26, 2012 at 5:39 AM, John Graham-Cumming wrote:
    On Mon, Nov 26, 2012 at 12:08 PM, Jed Smith wrote:
    It doesn't have to be an incompatibility. There's two fixes that work
    and remain compatibile but that change behavior quietly:

    1. Base the Priority constants at 8 instead of 0, to emit as "user".
    Yes, but that's kind of an ugly hack to make it just emit as user. I
    honestly think this is one of those cases where it's necessary to say
    'we made a mistake with the initial API; let's change it'.
    I couldn't agree with you more, and I am watching your code review
    with interest. Looks like a compromise is necessary, though, based on
    initial reaction (which I expected).

    As for RFC 5424, which I've seen come up in this thread and in the
    code review, don't bother. The history of RFC 5424 is sad, and its
    implementation state in the world is even sadder. My experience with
    5424 amounts to using the software written by the very person that
    wrote the specification, and even that didn't handle RFC 5424
    correctly right off the bat.

    Processes are probably never going to speak RFC 5424 to /dev/log,
    which I would expect is the main use case for log/syslog. Probably not
    worth the effort. I think Go should speak the lowest common
    denominator -- which you're working on -- to /dev/log in the standard
    library (or a remote host). If there's a desire for RFC 5424, it
    should be a third-party package, in my opinion. A lot of syslogds will
    break spec and accept a higher-precision timestamp in /traditional/
    syslog anyway, which is the only real win of RFC 5424 over "BSD".

    If you do get a chance to reconsider the log/syslog API (Go 2?),
    following the openlog(3)/syslog(3) approach might be beneficial.

    --
    Jed Smith
    jed@jedsmith.org

    --
  • John Graham-Cumming at Nov 26, 2012 at 5:37 pm

    On Mon, Nov 26, 2012 at 5:26 PM, Jed Smith wrote:
    As for RFC 5424, which I've seen come up in this thread and in the
    code review, don't bother. The history of RFC 5424 is sad, and its
    implementation state in the world is even sadder. My experience with
    5424 amounts to using the software written by the very person that
    wrote the specification, and even that didn't handle RFC 5424
    correctly right off the bat.
    Agreed. I have fallen back to simpler times and am not mentioning
    RFC5424 or trying to be compatible with it. The goal now is to be
    compatible with running code that's out there.

    John.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 15, '12 at 5:57p
activeNov 26, '12 at 5:37p
posts11
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase