thread-unsafe syslog code in libc?

John Polstra jdp at
Sun Aug 15 12:58:07 PDT 2004

On 15-Aug-2004 Robert Watson wrote:
> I recently resolved a kernel race reported by Martin Blapp in which a file
> descriptor had connect() called on it by one thread, and was
> simultaenously close()'d by another. The bug resulted in a kernel crash,
> which is certainly not the right response, and I'm working on a number of
> aspects of that problem. However, this also speaks to a race in user
> space.  The socket in question was being connected to /var/run/log, so I
> believe it was made from the libc syslog code.  A glance at
> src/lib/libc/gen/syslog.c suggests that things are indeed a bit
> un-threadsafe, especially in vsyslog(), where things get connected and
> disconnected a fair amount.

I don't see any repeated connecting and disconnecting in vsyslog
except under error conditions.  Here's the relevant code, with my
commentary non-indented:

        /* Get connected, output the message to the local logger. */
        if (!opened)
                openlog(LogTag, LogStat | LOG_NDELAY, 0);

Note that connectlog() is a no-op if we are already connected (the
expected case after the first call).

        if (send(LogFile, tbuf, cnt, 0) >= 0)

If the send succeeds (the normal case) we return here and don't

         * If the send() failed, the odds are syslogd was restarted.
         * Make one (only) attempt to reconnect to /dev/log.
        if (send(LogFile, tbuf, cnt, 0) >= 0)

The above is only to handle an unusual error case.

There is some thread-unsafeness here, but it doesn't look like it
would matter under normal conditions.


More information about the freebsd-threads mailing list