[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 11 Nov 2017 01:29:06 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Add SOCK_STREAM support for syslog
>If your primary goal is that no log data be lost, blocking SOCK_STREAM
>might be preferable to you. Generally I consider "critical services
>can't get delayed or deadlocked because of a problem with the logging
>system" as a higher priority requirement. If you can't ssh in to fix a
>problem because sshd is blocking in syslog() when you connect, you
>have a big problem.
But how can you tell the difference? The syslog() API does not
allow a process to specify what policy it wants: block or drop logs.
Relying on a system-wide setting, and an obscure one as that
(is /dev/log SOCK_STREAM or SOCK_DGRAM?), is a terrible way to
implement that policy. The right thing in this case is to always
do the reliable thing by default (don't drop data), and if a
process cannot afford to block when logging, then it should be
using other mechanisms to log.
Like, for instance, writing to a non-blocking file descriptor,
with a call to poll() beforehand and giving up after some timeout.
syslog() is just the wrong API for this. (It's the wrong API for
pretty much everything.)
skarnet.org programs always give the user an option to time out
when they may block. It's the only way to be safe. If sshd does not
do this, it's a design failure.
>Datagram send succeeds or fails atomically -- either the full packet
>is sent or nothing is.
This is a good argument, but is only as important as the integrity
of records. Between losing an entire log line and conflating a partial
one with the next, I'm not sure what's worse; syslog data is text,
which is easily recoverable, and it can be argued that some info is
better than no info. it is, again, a policy decision, one that the
libc shouldn't have to make.
>Datagram sockets are also nicer from a standpoint of being able to
>restart the logging daemon while there are chrooted clients. As long
>as a supervisor owns the socket and keeps it open, it just works to
>kill the logging daemon and start a new one receiving on the socket.
>But with streams, the logging daemon has to accept connections, and
>there's no simple way to hand them off to a new/restarted daemon. And
>if you can't do that, you cut off logging in all chrooted clients when
>restarting the logging daemon.
This implies a monolithic syslogd. My argument for SOCK_STREAM is
precisely that it allows syslogd to be implemented via a super-server,
inetd-like, with a "syslogd" program only handling one client
connection; in that case you can easily restart the server without
impacting existing clients. And to me, doing away with a monolithic
syslogd is the whole point of using SOCK_STREAM, so this argument
holds no water.
--
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.
