Spreadlog issue on FreeBSD
"Jay West" <[email protected]> Thu, 11 Mar 2004 09:00:24 -0600
| Newsgroups | gmane.comp.apache.mod-log-spread.user |
|---|---|
| Message-ID | <[email protected]> |
Since upgrading from an old version of spread/spreadlogd to the newest version on FreeBSD, we've had a bizarre issue I was hoping someone might shed some light on. This was definitely not a problem on the old version, but is on the new one. Our webservers send their weblogs to a spreadlogd machine using a perl script called "spreadlog", however, our spreadlog perl script is really just what we chose to rename a perl script that is included with mod_log_spread. I'm not sure what the actual name is, I believe in the mls distribution it is called spread_log_error.pl or something to that effect. In the comments in the script itself it is called "logger.pl". This distribution supplied script just writes stdin to the spreadlogd, taking a group name as a parameter. Anyways... we call the script in the webservers via: CustomLog "|/usr/local/sbin/spreadlog -g kd" combined When apache starts, it starts all the httpd processes, plus one process for each CustomLog that is piped to spreadlog (sp_log_error.pl). There are only two modifications we made to the stock script. We added a newline to the output (otherwise the logs showed up via spreadlogd all on one line), plus we put in a retry so that if it failed to connect to the spreadlog daemon it would automatically retry instead of printing "Could Not Connect" and just dying. On the old version of spread/spreadlogd, this setup worked great. When apache was started, all the customlog processes appeared. When apache was stopped, those customlog processes disappeared. But on the new version, when apache is stopped, those customlog (spreadlog aka sp_error_log.pl) processes stick around. Over time and several apache stop/starts, we get LOTS of those processes hanging around. In addition, when apache starts, more often than not, SOME of those customlog processes print a message about "Could Not Connect", but they don't just retry. The processes stay but they don't log. Does anyone have any thoughts on this? Thanks! Jay West Web and Network administrator Knight's Direct --- [This E-mail scanned for viruses by Declude Virus]