Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 01 Apr 2018 08:13:39 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Ben Woods <woodsb02@gmail.com>, Julian Elischer <julian@freebsd.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps
Message-ID:  <1522592019.49673.166.camel@freebsd.org>
In-Reply-To: <CAOc73CDgEK8=QHypg_eLMCGsadR6sC=u8AF6nkEdOrG75KpsdA@mail.gmail.com>
References:  <CAOc73CCzOoiq9YVC5DJgODC7yF21LCxNXR7aNfKc2FemGOR2cA@mail.gmail.com> <4fd424ca-ff93-315c-fa87-fb9c738b9b50@freebsd.org> <CAOc73CDgEK8=QHypg_eLMCGsadR6sC=u8AF6nkEdOrG75KpsdA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2018-04-01 at 18:24 +0800, Ben Woods wrote:
> My testing shows that if syslogd(8) is not running at the time a
> message
> comes in from syslog(3), the message is dropped (not buffered until
> syslogd
> is once again running).
> This means there would be no significant time delay issues causing
> incorrect timestamps if syslogd(8) adds the timestamp instead of
> syslog(3).
> https://svnweb.freebsd.org/base/head/lib/libc/gen/syslog.c?revision=3
> 26025&view=markup#l171

The important issue with source-side timestamping doesn't have to do
with whether syslogd is running or not, it has to do with mutiple
threads and processes feeding data to syslogd at high speed and
accurately timestamping the events being logged. Mutexes are involved
in libc syslog(3) for multithreaded apps, and buffers are involved
which can lead to arbitrary ordering of messages generated by various
processes, and only source-side timestamps can make it clear in what
order things really happened.

In addition, milliseconds are not nearly fine-grained enough for
fractional seconds.  Even microseconds aren't really good enough on
modern hardware.

-- Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1522592019.49673.166.camel>