Thanks for the pointer. After overriding SQUID_ARGS as proposed, squid seems to no longer be using syslog. It's my feeling that unless squid is modified to call syslog in a manner which can't block the main process, the default SQUID_ARGS should not include "-s". Since the information is already logged to cache.log, there is no data lost through making such a change and a substantial risk is eliminated.
See Debian bugs 205926 and 462581 for more general information on the bad effects of syslog using blocking IO in a daemon's select() or poll() loop. As for syslog-ng, unless they're including a non-blocking syslog client library, it only partially addresss the problem. Syslog-ng's multi-threaded model would help reduce cases where the syslog daemon might not immediately process logging requests, but it does not fully eliminate the possibility that the blocking write called by the standard POSIX syslog() might still block and hang up the entire squid process until it completes. One workaround would be to call the syslog function from an external child process, similar to how older squid versions (or newer versions when compiled with the --disable-internal-dns option) handled the blocking gethostbyname function. -- Brian Ristuccia [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
