Last modified: 2014-04-02 17:36:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65421, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63421 - CatScan2 web stopped working
CatScan2 web stopped working
Status: RESOLVED FIXED
Product: Wikimedia Labs
Classification: Unclassified
tools (Other open bugs)
unspecified
All All
: Unprioritized blocker
: ---
Assigned To: Marc A. Pelletier
https://tools.wmflabs.org/catscan2/ca...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-02 15:16 UTC by Magnus Manske
Modified: 2014-04-02 17:36 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Magnus Manske 2014-04-02 15:16:15 UTC
The scripts in my catscan2 tool are not responding. Used to work until about 3pm GMT on 2014-04-02. Webservice appears to be running; restarting it has no effect.

Haven't touched it in a while, and can't even get simple test scripts, so I assume the problem is upstream.

Example:
https://tools.wmflabs.org/catscan2/catscan2.php

idles for a minute, then comes back with "internal error". Other tools work fine. Some lighttp/PHP config issue?
Comment 1 Marc A. Pelletier 2014-04-02 15:40:03 UTC
No, it's a database issue: catscan2 has queries holding locks that have been running for several hours; I expect further queries simply pile up waiting to grab locks.
Comment 2 Magnus Manske 2014-04-02 15:47:29 UTC
I don't think so. The test script

https://tools.wmflabs.org/catscan2/catscan2_test.php

consists of the following code:
<?PHP
header('Content-type: text/html');
print "TEST" ;
?>


It's not loading either, and I would think it's not waiting for a database query...
Comment 3 Marc A. Pelletier 2014-04-02 15:49:00 UTC
No, that script isn't, but all of your lighttpd workers are (which means that attempting to run that test fails because it's starved).

This implies that the issue might be solvable with a timeout for the cases where user input causes a very long query to stall.
Comment 4 Magnus Manske 2014-04-02 16:01:30 UTC
But it also fails immediately after I restart lighttpd. That should have cleared the workers, right?

So, how do I get the tool working again?

Also, will adding a PHP set_time_limit prevent this from happening again? If not, how?

Finally, why did it stop today, when it apparently worked for months without incident? (there was one, a few month ago IIRC, but otherwise it seemed to be fine).
Comment 5 Magnus Manske 2014-04-02 16:45:44 UTC
OK, seems to be back. I'd still like to hear some specific prevention method for this though.
Comment 6 Marc A. Pelletier 2014-04-02 17:36:26 UTC
set_time_limit will indeed try to abort the /script/, but depending on how exactly you connect to the DB it may not abort a query in progress.

A quick google finds that the problem is not new; there are possible avenues of investigation at

http://stackoverflow.com/questions/9562124/php-mysql-set-connection-timeout
http://www.phpbb2refugees.com/viewtopic.php?p=7647&sid=028921ede498fddbc1ebfbd71ee37dcc

The short of it is that there doesn't seem to be a way to set a query timeout, but you could set up an alarm() to abort one that takes too long.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links