Mar 28 2019
Today (23 days later) there are 128 hits in dewiki_p (6 additional wrong pairs), 78 in frwiki_p (2 fewer), still none in eswiki_p, still 25 in itwiki_p.
Mar 23 2019
This is already implemented. Closing Task
Mar 22 2019
From my side (s51412__data) it is done. Thanks.
Mar 19 2019
From the few words there, it sound like the same problem.
Mar 12 2019
Mar 11 2019
I was not aware of this one. Worked fine on trusty :-(
tools.persondata@tools-sgebastion-07:~$ webservice --backend=kubernetes start
Looks like you already have another webservice running, with a gridengine backend
You should stop that webservice by issuing:
webservice --backend=gridengine stop
And then start it again with backend kubernetes by issuing:
webservice --backend=kubernetes start
Mar 5 2019
Mar 2 2019
Feb 28 2019
Hmm … seems to be my error.
Sorry, my mistake.
Well, I started all my jobs (for historical reasons) from crontab with -once. I have rewritten some job which does its work, sleeps some minutes and then runs again. So I do not have to start it over and over again.
Feb 27 2019
I accessed it from tools-bastion-02 with some script. Could be reproduces with command line
After a few minutes the problem vanished.
Feb 26 2019
Maybe a second account in the database would be a simpler solution to double the number of connections? (just my few cents)
I'm the happiest guy in the world!
Feb 25 2019
A dump would be fine. I do not need all, some a really large!
Feb 21 2019
It is already set.
Feb 19 2019
Would be fine when the data of s51412__data could be saved/restored onto the new server too.
Feb 14 2019
Generally a user limit is okay.
Feb 13 2019
Oct 25 2018
I think there is no need to run such a query by cron or similar.
Oct 1 2018
Aug 11 2018
Jul 16 2018
Yes! I have even started some virtual machine which I did not use for month and there the errors show up too, I tried en.wikipedia.org and fr.wikipedia.org (for sure I never visitied fr.wikipedia.org, since I do not understand that language).
Jul 15 2018
On my local machine here at home I have installed a version from december 2017, when I grep in the source-hell I find …
Jul 2 2018
Just an example: https://de.wikipedia.org/wiki/Internet_Movie_Database or en-wp: https://en.wikipedia.org/wiki/Robert_W._Chambers
Jul 1 2018
Apr 25 2018
Apr 1 2018
A different example: ref-tags are enclosed in nowiki-tags
Mar 16 2018
enwiki works the same way as dewiki does. There is just an additional parameter "wiki=", example: https://tools.wmflabs.org/wikihistory/wh.php?wiki=enwiki&page_title=Crooked+House Okay, I did not change the frontend https://tools.wmflabs.org/wikihistory/ this is still the same as before and works for the german WP only.
Feb 21 2018
I actually changed it a little bit. I have 10 queues. When I started to maintain this tool, somewhen in September/October it had 4 queues, but at that time it served only de-wiki (and two very small ones: ndl and als). Now I serve en-wiki too. 9 queues are for different sizes of the page. The change I did already is polling fewer times. The processes for the large files poll now every 15 seconds since the computation takes a long time, so it does not matter if the user has to wait 5 minutes or 5 minutes and 15 seconds. The queue for the small pages now polls every 2 seconds (instead of 1 second). 1 second was not invented by me, that was the value when I started to maintain the tool.
I can reduce the number ob jobs to ~4 if that is enough.
Nov 8 2017
In the webserver-logfile of the tool wikihistory I see 2208 entries similar to the following
2017-11-07 11:42:14: (mod_fastcgi.c.2673) FastCGI-stderr: PHP Warning: mysql_connect(): Too many connections in /mnt/nfs/labstore-secondary-tools-project/wikihistory/db.inc.php on line 7 2017-11-07 14:32:16: (mod_fastcgi.c.2673) FastCGI-stderr: PHP Warning: mysql_connect(): Too many connections in /mnt/nfs/labstore-secondary-tools-project/wikihistory/db.inc.php on line 7
Nov 7 2017