[00:38:42] !log deployment-prep rebuilding search indecies after cirrussearch update [00:38:49] Logged the message, Master [02:40:56] Coren, ping [02:41:17] Coren, Wikidata is missing the user table. What happened to it? [02:41:36] Cyberpower678: there was a security issue and it's temporarily been removed [02:41:41] he said it should be back in a few days [02:41:53] legoktm, security issue? [02:42:02] yes [02:42:08] ?? [02:42:23] i'm not going to disclose it until they do [02:42:39] It explains why ActiveStats on Wikidata is cocked up. [02:42:56] Posted a note on AN [02:43:14] legoktm, you've only made 200 admin actions in the last 6 months. :p [02:43:30] That's not true [02:43:39] Not even close. [02:44:09] legoktm, I know. The bot can't retrieve your information as long as the user table is missing. [02:44:17] oh [02:44:21] why not? [02:44:36] ug_group uses user_id [02:44:41] so just use that as your primary key [02:44:46] So the bot is only able to retrieve MediaWiki edits and crat actions. [02:44:58] i don't understand? [02:45:06] can i see your code? [02:45:45] It pulls all of the admin actions from the db for speed. Unless the user is a crat, it uses the API. [02:45:56] MediaWiki edits are retrieved from the API. [02:46:00] um [02:46:10] i can pull a users's admin actions without the user table [02:46:31] It uses the user table to retrieve the UID of a user. [02:46:31] select count(*) from logging where log_type='blah' and log_user=? [02:46:40] well, use the API for that then :P [02:46:48] log_user needs a user_id [02:46:56] use the API [02:47:04] Unnecessary [02:47:10] wait [02:47:16] where are you getting a list of sysops from? [02:47:16] DB is much faster. [02:47:24] are you using ug_group='sysop'? [02:47:30] that gives you user_id... [02:48:00] :O [02:48:15] * Cyberpower678 needs to rewrite the allusers function on Peachy [02:48:56] But not tonight [02:49:22] Err. That means the adminstats on Wikidata are cocked up as well. [02:51:53] Or will be cocked up once the bot runs. [04:36:26] Cyberpower678: Yes, there's going to be a post shortly that explains why some databases temporarily went away. [05:00:32] Cyberpower678: https://meta.wikimedia.org/wiki/October_2013_private_data_security_issue [05:00:36] and for anyone else here... [10:52:19] petan, ping [11:01:58] Hi [11:02:07] Anyone want to do a very quick query? [11:03:21] What's the query? [11:04:33] Find transclusions of {{cite newsgroup}} on English Wikipedia using the googleid param ... [11:05:00] or more precisely |googleid= in the template invocation [11:05:05] Oh.\ [11:05:13] Let me see if I can do that. [11:05:44] It should be less than 500 pages to check overall.. [11:06:09] Yea. I'm not sure if I can pull template parameters. [11:06:45] I am checking pages manually [11:07:07] but a qury to catch the straglers is appreciated [11:07:49] You would likely need a bot script. [11:08:44] You're going to need a bot script to parse the templates with. [11:09:13] The database nor the API stores which template uses what parameters, from what I know. [11:10:00] Is there a tool for running grep against wikitext? [11:10:48] Erm, you'll need to ask someone else. I'm no linux expert. [11:10:54] Sorry. [11:16:47] Cyberpower678 pong [11:17:40] Can you jump a few of my scripts for me. Because of the security issue, Cyberbot I got forcibly logged and now is stuck because it doesn't like to edit as an IP. [11:17:49] I'll give you the PIDs [11:18:11] 948579 [11:18:16] 948989 [11:18:19] 977505 [11:18:27] 977626 [11:18:38] 977630 [11:18:46] 977637 [11:19:02] Actually don't do 977637 [11:19:22] 977638 [11:19:28] 977696 [11:19:44] 977742 [11:19:53] 977768 [11:20:02] 977807 [11:20:09] 977861 [11:20:18] That's all of them. [11:20:22] petan, ^ [11:20:46] what u want? [11:20:53] define "jump a script" [11:21:15] petan, kill the script without killing the process. [11:21:26] how can I do that? [11:21:31] !kill [11:21:38] ... [11:21:39] petan, you've done it before. [11:21:45] I don't remember [11:22:12] You killed the php process forcing the process to restart. [11:22:14] you really need to implement some admin interface that can do this [11:22:19] aha [11:22:28] so you mean kill the process but don [11:22:31] 't kill job [11:22:35] Yes. [11:22:36] aha [11:22:39] that makes some sense then [11:23:05] T13|needsCoffee, what's wrong? Did your client run out of coffee? :p [11:23:21] Yes [11:23:30] ok [11:23:56] petan, let me know when that's done. They're all in the cyberbot node [11:24:10] but last time I was killing all of them [11:24:16] I can't recognize which is which [11:24:23] so I can either kill all or none [11:25:01] aha now I see [11:25:08] Actually Coren|Sleep said I should be able to manage the Cyberbot node's resources. But he never told me how. [11:25:11] 00:00:00 /bin/bash /var/spool/gridengine/execd/tools-exec-cyberbot/job_scripts/977630 [11:25:22] Cyberpower678 lol man [11:25:31] you need to learn some programming then [11:25:41] what is it written in [11:25:48] if it's python it's mission impossible then :P [11:25:58] but if it's c or c++ it's pretty easy [11:26:15] three of them are python. The rest is PHP, and I know you can kill it. [11:26:27] aha in that case it's mission impossible [11:26:35] you can't manage resources of anything that uses GC [11:26:51] No it's not. You've killed the process before. [11:27:02] What's making it mission impossible now. [11:27:40] !paste [11:27:40] http://tools.wmflabs.org/paste/ [11:27:58] ? [11:28:00] http://tools.wmflabs.org/paste/view/7b269607 [11:28:07] can you tell me which of these needs to be killed? [11:29:18] yes. [11:33:40] petan, http://tools.wmflabs.org/paste/view/e5de7cd5 [11:37:04] done [11:38:44] petan, are you sure. Cyberbot I doesn't seem to be coming back to life. [11:39:13] I am sure all processes you listed for kill except for my grep which was already dead were killed [11:39:23] I mean all processes in that paste [11:39:27] they all exited [11:39:44] Let's see... [11:39:49] Damn WMF [11:39:57] fresh list: [11:39:59] petrb@tools-exec-cyberbot:~$ ps -ef | grep 50404 [11:40:00] 50404 14369 14363 0 Oct01 ? 00:00:00 /bin/bash /var/spool/gridengine/execd/tools-exec-cyberbot/job_scripts/1152835 [11:40:01] 50404 14371 14369 69 Oct01 ? 1-17:36:44 /usr/bin/php5 externallinksfull.php [11:40:02] 50404 22421 22419 0 11:05 ? 00:00:00 /bin/bash /var/spool/gridengine/execd/tools-exec-cyberbot/job_scripts/1176710 [11:40:03] 50404 22422 22421 32 11:05 ? 00:10:57 /usr/bin/php5 externallinks.php [11:40:04] petrb 25107 23542 0 11:39 pts/0 00:00:00 grep --color=auto 50404 [11:40:14] wanna kill these too? [11:40:18] NOOOOO [11:40:20] ok [11:40:20] Don't [11:40:37] Those belong to Cyberbot II, and they're functioning fine. [11:40:43] right [11:40:50] I think you should start the bot again? [11:40:55] or maybe wait for sge to recover it [11:41:50] How do you access tools-exec-cyberbot? [11:41:58] ssh [11:42:12] ssh? [11:42:15] yes [11:42:21] I'm already sshed into labs. [11:42:29] Do ssh into the node specifically? [11:42:30] ssh tools-exec-cyberbot [11:42:35] yes [11:42:49] Do I have access to it? [11:42:53] no idea [11:42:54] try it? [11:43:15] I need the host. [11:43:22] tools-exec-cyberbot [11:43:40] ssh tools-exec-cyberbot.pmtpa.wmflabs [11:44:03] I'm in [11:44:17] well, you can sudo -u local-cyberbot [11:44:23] and kill all the processes yourself [11:44:39] How do you kill? [11:44:46] there is command called kill [11:44:48] see man kill [11:45:24] I gotta go now. Be back later [11:45:29] ok [13:22:42] !log deployment-prep finished rebuilding search indexes after cirrussearch update [13:22:49] Logged the message, Master [13:44:58] petan, ping [13:45:08] ? [13:45:45] petan, I'm afraid I'm going to kill labs. How do I kill all? [13:46:03] what [13:46:59] using the kill command on the cyberbot node. Can you give me a step by step guide to killing everything in that node and forcing the job to restart. [13:48:21] petan, ^ [13:48:42] killing everything? [13:48:45] what are you talking about [13:48:52] killing everything that runs as your bot? [13:49:02] Yes. [13:49:19] sudo -u local-cyberbot killall -u local-cyberbot [13:50:49] petan, that deleted all of my jobs. [13:51:01] That's not what I wanted. [13:51:25] I thought it would simply exit the script and force a restart. [13:54:31] petan, I readded all of the jobs, but now the queue seems stuck. [13:55:36] petan, nevermind. It's just taking ridiculously long to start the script. [17:00:20] Coren: we just killed beta labs: A database query error has occurred. This may indicate a bug in the software.Function: efUserIsAffectedError: 1146 Table 'centralauth.bug_54847_password_resets' doesn't exist (10.4.0.53) [17:01:15] Coren: I think you were doing something with some password resets? [17:01:48] chrismcmahon: Not I. I'll poke the devs working on this. [17:02:28] Coren: thanks, or let me know who that might be [17:02:49] There was an emergency patch thing deployed in production that the beta DB clearly wasn't ready for; it should be a simpleish fix. [17:04:32] Coren: understood, thanks [17:07:43] chrismcmahon: Reedy and apergos are on it. [17:13:36] andrewbogott: fixed, deploying... [17:13:56] andrewbogott: try now? [17:13:59] deployed [17:14:51] chrismcmahon: Should be fixed when beta nexts updates config [17:14:58] thanks Reedy [17:16:54] YuviPanda: yep, looks right. Thanks. [17:17:06] andrewbogott: poke me if you need other changes [17:17:15] I'm sure I will :) [17:51:50] andrewbogott: thoughts on deprecating mediawiki_singlenode in favor of https://wikitech.wikimedia.org/wiki/Labsvagrant? [17:52:20] YuviPanda: I don't object but it'll be a while before I have time to think about it... [17:52:31] There are various legal tweaks in singlenode that will have to be ported over. [17:52:40] andrewbogott: hmm, I can look at those and make sure they happen [18:26:34] Coren, ping [18:26:46] pong? [18:39:36] Coren: is it possble to check peak memory usage of a task after it finished? [18:39:47] so I can choose -mem value of the next run more wisely [18:42:11] [bz] (8ASSIGNED - created by: 2Kunal Mehta (Legoktm), priority: 4Normal - 6normal) [Bug 49088] archive table not accessible - https://bugzilla.wikimedia.org/show_bug.cgi?id=49088 [18:43:37] liangent: Yes, you can use qacct -j (jobnumber|jobname) [18:44:01] liangent: maxvmem is the key you are interested in [18:44:56] liangent: most useful: "qacct -j jobname | grep maxvmem" [18:46:07] Coren: hmm got it but it seems smaller than the one on http://tools.wmflabs.org/?status [18:46:50] Hm, that would be odd. [18:47:24] Coren: well maybe I didn't remember it correctly [18:48:19] Also, there's a possible confusion between 1000 megs and 1024 Megs. Gridengine isn't entierly consistent it its use of either. [18:48:39] (And when specified on the command line, lowercase is powers of 10, uppercase is powers of 2) [18:48:46] So 64m << 64M [18:48:55] Yes, it's t3h suxx0rz. [18:51:12] Coren: if I my memory is correct, it's some 2G vs 4G difference [18:52:04] That's more than I would expect from simple unit scale errors. :-) [19:26:37] [bz] (8RESOLVED - created by: 2Maarten Dammers, priority: 4Immediate - 6critical) [Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases - https://bugzilla.wikimedia.org/show_bug.cgi?id=54847 [19:56:51] @notify DGarry [19:56:51] I'll let you know when I see DGarry around here [20:06:15] db replica stopped from zhwiki? didn't check other wikis [20:11:54] [bz] (8NEW - created by: 2Liangent, priority: 4Unprioritized - 6normal) [Bug 54934] DB replica for s2 stopped - https://bugzilla.wikimedia.org/show_bug.cgi?id=54934