Date: Fri, 10 Nov 2017 19:41:31 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Add SOCK_STREAM support for syslog On Sat, Nov 11, 2017 at 12:29:25AM +0000, Laurent Bercot wrote: > >I suspect and seem to remember (but haven't looked at it lately) that > >SOCK_STREAM has some undesirable properties from a standpoint of > >logging and that SOCK_DGRAM is what you want if possible. > > Oh really? I would very much like to hear what those "undesirable > properties" are. AIUI, datagrams are specified as unreliable, which > is exactly what you *don't* want when logging, so it beats me why > people would ever prefer SOCK_DGRAM over SOCK_STREAM. I suspect the > answer is close to "because traditional syslogd is easier to implement > with datagrams", which I do not hold in much regard. I don't understand unix socket semantics well enough to be sure of all the details, but here are a few as I understand them. Feel free to correct if they're wrong. 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. Datagram send succeeds or fails atomically -- either the full packet is sent or nothing is. If you wanted to avoid blocking indefinitely with stream sockets, you're stuck once you've sent a partial log line; if you can't get the socket writable again to continue sending, you'll either corrupt this and the next message, or you have to disconnect and reconnect (may not be an option with chroot). 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. Rich
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.