Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55997001.7080808@skarnet.org>
Date: Sun, 05 Jul 2015 19:57:21 +0200
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] close syslog socket on error to recreate it later

On 05/07/2015 19:18, Rich Felker wrote:
> This may be okay, but are there possibly errors which are transient
> and do not indicate a broken connection? EINTR comes to mind. I wonder
> if the close logic should be default on any error but known-transient
> ones (EINTR only?) or if it should only be done on EPIPE or whatever
> error we get when the other end of the socket was closed.

  The problem is that syslog() does not return an error code, so how
would you treat transient errors?
  (Have I already mentioned that syslog() sucks and the right thing
is not to use it? I think I may have. Maybe even several times. :))

  There are two choices here:
  - either declare that syslog() should be reliable and switch to
/dev/console logging as soon as a hint of a problem occurs. (Maybe
even retry connecting to /dev/log for every message, in case syslogd
has restarted.)
  - or declare that it is unreliable and just do nothing on EINTR,
EMSGSIZE, ENOBUFS, EIO and EAGAIN, while switching to /dev/console
on other errors.

  In any case, I think it's a good idea to use MSG_NOSIGNAL in the
send().

-- 
  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.