Bug 194751

Created attachment 148911 [details]
proposed patch

Issue:  Calls to syslog() drop the first message sent after syslogd is restarted.


Effect:  Generally this results in only a single missing message, which is easily overlooked.  However, some server daemons (such as afpd) are quiet until they spawn their children, and the first message of each child is dropped, since they inherit their parent's (broken) connection state.  In the case of afpd, this means that all "Login by" messages are dropped after syslogd is restarted.

This bug affects 9.1-RELEASE and all newer versions, up through at least 10.1-RC4.


Cause:

The following commit was in error and broke r14332:

<http://svnweb.FreeBSD.org/base?view=revision&revision=228193>:
'Tweak the r137233 fix to r136283 -- Code was making two send() attempts
vs. the comment documented "If we are working with a privileged socket,
then take only one attempt".  Make the code match.'

Unfortunately, the code was more correct than the rather ambiguous comment.  The comment raises two cases:  #1 in which syslogd has been restarted, and #2 in which the socket buffers are full (a possible DoS).

To fully cover the case #1, we *need* to resend the message (just once) after reconnection.

Furthermore, looking at the precursor to <http://svnweb.FreeBSD.org/base?view=revision&revision=136283>, we see the original intent of resending once ("one attempt") to address this case.


Turning toward the second half of the rationale for r228193:

'Furthermore, critical privileged applications that [over] log a vast amount
can look like a DoS to this code.  Given it's unlikely the single reattempted
send() will succeeded, avoid usurping the scheduler in a library API for a
single non-critical facility in critical applications.'

The confidence that the single reattempted send() is "unlikely" to succeed is misplaced.  In the case where syslogd has been restarted, it will reliably succeed.  However, as previously coded, the single resend was also being attempted when the buffer was full, which is indeed unlikely to succeed.

Therefore, the proposed patch tries to reconnect and resend once if the failure was not due to a full buffer, without involving the scheduler.  It also corrects and clarifies the comment.  (An alternate approach would be to refactor the code and comments to treat the two cases entirely separately, but this patch aims for the fewest necessary code changes.)

This patch should be applicable to all affected releases (9.1-RELEASE and newer).