From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12085 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Add SOCK_STREAM support for syslog Date: Fri, 10 Nov 2017 19:41:31 -0500 Message-ID: <20171111004131.GU1627@brightrain.aerifal.cx> References: <1510319851.23177.3.camel@mittwald.de> <20171110140749.GC15263@port70.net> <20171110171406.GQ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1510360905 10040 195.159.176.226 (11 Nov 2017 00:41:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Nov 2017 00:41:45 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12101-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 11 01:41:41 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eDJrg-0002PN-4F for gllmg-musl@m.gmane.org; Sat, 11 Nov 2017 01:41:40 +0100 Original-Received: (qmail 15495 invoked by uid 550); 11 Nov 2017 00:41:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15475 invoked from network); 11 Nov 2017 00:41:43 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12085 Archived-At: 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