In D33199#750858, @dmitry.wagin_ya.ru wrote:

In my opinion, the original fix is indirectly related to the problem described by Alan.

In D33199#750852, @markj wrote:

Yes, it's necessary to adjust SO_SNDBUF, but not sufficient. It does matter what size the buffer is on reception, libc should not assume that syslogd is the only possible receiver.

Of course, syslogd is not the only possible receiver. But there is no way for the sender to influence the receiver. syslog(3) should just not hang.

In D33199#750851, @asomers wrote:

Real problem is not solved (infinite loop on sending).

The feature which is needed for real users is destroying in the RELEASE branch (log messages over 1kb).

What do you mean by "destroying in the RELEASE branch"?

In D33199#750825, @markj wrote:

In D33199#750268, @dmitry.wagin_ya.ru wrote:

Set SO_SNDBUF change what limit net.local.dgram.maxdgram=2048

I don't understand what you mean by this. As Alan pointed out, the value of SO_SNDBUF is not very important, it just controls the maximum size of a datagram. When a message is sent over a unix socket, the message is placed directly in the receive buffer. So, we need some other solution to enable large syslog messages.

I'm not sure about the SO_RCVPEERBUF idea: the receiver can change its recv buffer size at any time, so there's still some potential for problems. The default socket buffer sizes have been the same for a very long time, and I suspect that we can increase them without harm...

Set SO_SNDBUF change what limit net.local.dgram.maxdgram=2048

In D33199#750243, @markj wrote:

Ok with me since it fixes a regression. I do wonder if it's finally time to up the default socket buffer sizes though. I'm a little surprised that rsyslog uses the default.

changed some messages

• fixed "#define" position
• revert some unimportant changes

ping

ping

added a cast to void

man:
Moved new sentences to new lines.
Added articles.

Font size for BDF font files is determined not only by FONTBOUNDINGBOX.