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.