In 0a5029ea, issue #81, the persistent blocking delay for unresolvable remote log targets was fixed. However, the initial delay before getaddrinfo() time out remains.
As mentioned before, this is caused by the default values for timeout (retrans + retry) in the GLIBC resolver, see /etc/resolv.conf or resolver(5) for details. The GLIBC defaults are timeout:5 and attempts:2, meaning an incurred 10 second delay for each log message.
The problem is exacerbated at startup because a) no network connection is available, meaning any otherwise resolvable names also trigger this, and b) there's a lot of logging happening at startup.
A portable way to solve this seems to be to adjust retrans and retry only for syslogd. Since syslogd has its own retry loop anyway this seems to be best way forward:
void set_resolver_timeout(void)
{
res_init(); /* Ensure _res is initialized */
_res.retrans = 1; /* Timeout in seconds */
_res.retry = 1; /* Number of retries */
}
In 0a5029ea, issue #81, the persistent blocking delay for unresolvable remote log targets was fixed. However, the initial delay before
getaddrinfo()
time out remains.As mentioned before, this is caused by the default values for timeout (
retrans
+retry
) in the GLIBC resolver, see/etc/resolv.conf
or resolver(5) for details. The GLIBC defaults aretimeout:5
andattempts:2
, meaning an incurred 10 second delay for each log message.The problem is exacerbated at startup because a) no network connection is available, meaning any otherwise resolvable names also trigger this, and b) there's a lot of logging happening at startup.
A portable way to solve this seems to be to adjust
retrans
andretry
only for syslogd. Since syslogd has its own retry loop anyway this seems to be best way forward: