[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 14 Aug 2015 12:08:05 +0200
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: /dev/log: datagram, stream, both?
On 14/08/2015 05:10, Rich Felker wrote:
> Obviously I'd rather not do this, but if there's a convincing argument
> that it's needed for compatibility with real setups we could consider it.
Well, the only thing I can say is: I have a SOCK_STREAM server, it's
working, people use it. As far as I know, there's a commercial embedded
box somewhere out there that uses it, if they finally managed to ship
that... thing.
Of course, it wouldn't really matter for *that* embedded box, which
uses glibc. (Yeah.) But who knows, maybe they could be touched by
divine grace and recompile everything with musl. Miracles happen,
especially when they result in breaking things.
And I very much intend to work on more embedded projects in the
future, with enough control to make musl mandatory.
> Part of being a convincing argument would be showing that
> SOCK_STREAM is a documented feature that's supposed to work rather
> than historical baggage
Well, there's basically *no* documentation for that part of syslog
that I can find, and nothing is clear. So from my point of view,
anything is fair game; nothing even says that syslog() has to use
/dev/log as a communication point, except convention. That convention
is pretty strong, but that's all it is. The convention that syslog()
should use datagrams, however, is weak.
> but even then, since the current code works
> with all widely used log daemons, I think we'd also want a strong
> argument why stream is better than datagram for your setup.
Stream is better than datagram because it can be handled by a
superserver. With stream, I can listen(), accept() a connection per
instance of openlog, and fork a private ucspilogd process that logs
one stream of data from a unique source: this makes for fewer lines
of code, and easier log processing, as if daemons were writing to
stderr. The client is authenticated once, at connection time.
Datagram, on the other hand, enforces that there is only one instance
of the syslogd server, handling messages from all the syslog()s on the
machine. It enforces that its configuration will be global. Clients
are authenticated on every log message, so if the logger needs to
separate logs depending on client identity, its efficiency decreases
with the amount of data. Note that the reason why widespread setups
don't separate logs depending on client identity is that widespread
syslogd implementations make this difficult !
With SOCK_STREAM, I can mitigate a large part of why syslog() is bad
and implement a complete syslog server with very little code in an
efficient way. With SOCK_DGRAM, I can just hang my hat and go home,
admit that there's no doing better than current syslogd implementations,
and get drunk when people start using journald on embedded boxes because
it's so much better (tm).
> If SOCK_STREAM support does end up being deemed a feature that should
> be added, some careful consideration should be made to how the
> fallback and reconnection logic should work.
Design question first: why do you keep the datagram socket connected
instead of just using sendto()?
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
