Hi Warren,
At this point, I would recommend setting Debug -1 and then stop/start apache, and send me error_log from start until freeze. Then stop apache, and get me a tar/gzip copy of the directory /tmp/asp *unless* there is sensitive data in the data structures in which case you should not be sending me that.
It may be something that is being stored in $Session or $Application that is killing things, and is only specific to that DBM format.
Also, if all this debugging is just taking too long, then you might do something like this just for this one server:
# httpd.conf <Perl> use Apache::ASP::StateManager; $Apache::ASP::State::DefaultStateDB = 'DB_File'; </Perl> PerlSetVar StateDB DB_File # end httpd.conf
By default Apache::ASP uses SDBM_File for the internal database storage. You can also try the new PerlSetVar without the <Perl> block. You can also try GDBM_File without using DB_File, either way as you may only have one or the other installed on your system.
Note these things in <Perl> blocks in not officially supported, but this is a worst case scenario where SDBM_File just isn't working for you for the internal database, and I think this should work to override it. Note also, if you use the <Perl> method, you need to delete the /tmp/asp directory between changing the DefaultStateDB setting, as Apache::ASP is not used to this being changed at runtime, its a hard coded global in the code.
Regards,
Josh
Warren Young wrote:
Josh Chamas wrote:
What is the state of the system when it locks up?
These systems are installed in schools, so they're only being used from roughly 7am to 4pm. This problem is happening within that window, while it is being used during the day. We have never seen it lock up in this way over night.
Is the machine under load
To the extent that 5500 hits per day is "load", yes. :)
There seems to be a loose correlation between the problem and load: this site is one of the heaviest users. We have heavier users, though, that aren't seeing the problem.
is a process spinning out of control,
We don't notice a busied out CPU, if that's what you mean. And, I wouldn't think anything is truly deadlocked, since all it takes is removing the ASP state directory to fix the problem.
is there any errors in the error_log that look interesting?
No, but then we send a lot of stuff to error_log ourselves. And, we don't have Debug turned up. Should we?
Does restarting the web server help things without removing the /tmp/asp
entirely,
No.
or is removing that directory the only fix?
Yes.
If the details you provided about /tmp/asp are before removing but after a freeze, then I would say there is nothing that looks out of the ordinary there that would raise concern on my side.
Hmmm... Would having the files help?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
