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>