Jay West
2004-03-11 15:00:24 UTC
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]
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]