[00:25:28] PROBLEM - Puppet on test1 is WARNING: WARNING: Puppet is currently disabled, message: reason not specified, last run 50 seconds ago with 0 failures [00:25:35] [02miraheze/ManageWiki] 07MacFan4000 pushed 032 commits to 03master [+0/-0/±3] 13https://git.io/fNTd7 [00:25:37] [02miraheze/ManageWiki] 07MacFan4000 03aeeebca - Revert "allow URLs in helptips" This reverts commit 755fc1539b301d8fa291eff255c0f176e8509aa7. [00:25:38] [02miraheze/ManageWiki] 07MacFan4000 03944b8bc - Link to mw.org pages [00:29:20] [02miraheze/ManageWiki] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTFk [00:29:22] [02miraheze/ManageWiki] 07MacFan4000 036b0c472 - Add i18n [00:32:32] [02miraheze/mediawiki] 07MacFan4000 pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTFB [00:32:34] [02miraheze/mediawiki] 07MacFan4000 035ba69a3 - Update mw [00:34:13] [02miraheze/mw-config] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTFr [00:34:14] [02miraheze/mw-config] 07MacFan4000 037d5a14e - mw config [00:34:27] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [00:48:08] [02miraheze/ManageWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTbZ [00:48:09] [02miraheze/ManageWiki] 07paladox 036b9b072 - fix syntax [00:48:49] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTbc [00:48:50] [02miraheze/mediawiki] 07paladox 03d61c495 - Update ManageWiki [00:52:28] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [00:53:53] !log sudo -u www-data php rebuildLocalisationCache.php --wiki test1wiki on mw* [00:53:57] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [01:06:05] [02miraheze/ManageWiki] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTNc [01:06:07] [02miraheze/ManageWiki] 07MacFan4000 03adcb831 - Update en.json [01:07:06] [02miraheze/ManageWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTNl [01:07:07] [02miraheze/ManageWiki] 07paladox 034398174 - Update SpecialManageWiki.php [01:08:22] [02miraheze/mediawiki] 07MacFan4000 pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTNB [01:08:24] [02miraheze/mediawiki] 07MacFan4000 03a8d5719 - Uodate mw [01:10:24] [02miraheze/ManageWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTNu [01:10:26] [02miraheze/ManageWiki] 07paladox 03976879f - Update SpecialManageWiki.php [01:11:09] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTN2 [01:11:10] [02miraheze/mediawiki] 07paladox 03f5dd736 - Update ManageWiki [01:13:34] miraheze/ManageWiki/master/976879f - paladox The build passed. https://travis-ci.org/miraheze/ManageWiki/builds/402470549 [01:32:52] [02miraheze/puppet] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTAI [01:32:53] [02miraheze/puppet] 07paladox 0303f7d77 - Update rewrite.py [02:03:26] RECOVERY - Puppet on misc4 is OK: OK: Puppet is currently enabled, last run 2 minutes ago with 0 failures [02:42:09] [02miraheze/ManageWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTpI [02:42:10] [02miraheze/ManageWiki] 07paladox 03dc16f2e - Add isset check for $ext['skin'] [02:42:45] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTpq [02:42:47] [02miraheze/mediawiki] 07paladox 038da2e7d - Update ManageWiki [02:52:06] [02miraheze/CreateWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNTpa [02:52:08] [02miraheze/CreateWiki] 07paladox 030f1b9f7 - Add a isset check to getSettingsValue [02:52:45] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTpw [02:52:47] [02miraheze/mediawiki] 07paladox 03dce7307 - Update CreateWiki [02:56:06] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNTpo [02:56:08] [02miraheze/mediawiki] 07paladox 03fc9ad9d - Update DynamicPageList3 [03:05:28] PROBLEM - Puppet on mw1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Exec[git_pull_MediaWiki core] [04:38:28] PROBLEM - Disk Space on db4 is WARNING: DISK WARNING - free space: / 76924 MB (20% inode=95%): [04:50:48] PROBLEM - Current Load on swift1 is WARNING: WARNING - load average: 3.54, 3.19, 2.88 [04:54:47] RECOVERY - Current Load on swift1 is OK: OK - load average: 3.01, 3.12, 2.92 [05:02:47] PROBLEM - Current Load on swift1 is WARNING: WARNING - load average: 3.52, 3.40, 3.11 [05:11:25] paladox: is findInactiveWikis.php ran automatically? (I remember some plans about that) [05:54:26] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [06:02:27] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [07:22:06] [02miraheze/ManageWiki] 07Reception123 pushed 031 commit to 03master [+0/-0/±2] 13https://git.io/fNkIV [07:22:08] [02miraheze/ManageWiki] 07Reception123 03c490f02 - revert back to stable Per John [07:22:10] ^ JohnLewis [07:23:51] [02miraheze/mediawiki] 07Reception123 pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNkIi [07:23:52] [02miraheze/mediawiki] 07Reception123 03e743067 - Update ManageWiki [07:24:28] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [07:27:10] !log sudo -u www-data php rebuildLocalisationCache.php --wiki test1wiki on mw* [07:27:14] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [07:32:26] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [07:43:49] JohnLewis: not sure why links are still appearing https://meta.miraheze.org/wiki/Special:ManageWiki/metawiki [07:43:50] Title: [ Permission error - Miraheze Meta ] - meta.miraheze.org [07:43:57] since I went back to the change you made before [07:44:27] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [07:45:42] [02miraheze/mw-config] 07Reception123 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNktt [07:45:43] [02miraheze/mw-config] 07Reception123 0317a5285 - Revert "mw config" This reverts commit 7d5a14e18829365414435ab472a882b7c1958c77. [07:53:08] ^ paladox not sure why the change isn't reverting [08:37:17] Reception123: run the lc? Also it’s because of the change [08:37:27] Chace [08:37:32] I did [08:37:43] cache [08:37:56] Reception123: cache :) [08:38:25] paladox: I did and the links are still there for me [08:39:26] Hmm [08:41:32] Reception123: check on mw* that it pulled your change [08:41:45] And also updated the submodule [08:41:58] Though this could be varnish cache [08:47:39] Reception123: bbl. though if this is cache to confirm follow https://meta.miraheze.org/w/index.php?title=Tech:Varnish&mobileaction=toggle_view_desktop#One-off_purges_.28bans.29 [08:47:41] Title: [ Tech:Varnish - Miraheze Meta ] - meta.miraheze.org [08:48:05] ban req.http.Host == meta.miraheze.org [08:48:14] JohnLewis: is that correct ^^ [08:48:26] Bbl [08:49:01] paladox: ok [08:49:13] paladox: also, https://phabricator.miraheze.org/T3091#63121 [08:49:14] Title: [ ⚓ T3091 Better design for ManageWiki with separate collapsible parts for each thing ] - phabricator.miraheze.org [08:49:23] so on test1 please leave the change, so we can finish working on that [08:50:01] Ok [08:50:11] paladox: hmm yes the change wasn't pulled [08:50:21] paladox: so do you think you could do a landing page? [10:12:27] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [10:44:27] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [10:52:28] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [10:57:28] PROBLEM - JobQueue on mw3 is CRITICAL: JOBQUEUE CRITICAL - job queue greater than 300 jobs. Current queue: 5535 [11:34:28] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [11:42:27] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [12:04:26] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [12:24:11] Hello [12:36:26] PROBLEM - HTTP 4xx/5xx ERROR Rate on cp4 is WARNING: WARNING - NGINX Error Rate is 44% [12:38:26] RECOVERY - HTTP 4xx/5xx ERROR Rate on cp4 is OK: OK - NGINX Error Rate is 5% [12:55:28] RECOVERY - JobQueue on mw3 is OK: JOBQUEUE OK - job queue below 300 jobs [13:44:26] PROBLEM - Puppet on misc1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Apt_key[Add key: F86AA916A2195E121AEDB11437BBEE3F7AD95B3F from Apt::Source grafana_apt] [13:52:27] RECOVERY - Puppet on misc1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [14:34:27] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNk5K [14:34:28] [02miraheze/mediawiki] 07paladox 033592a20 - Update RandomGameUnit to the master branch This is recommended by mw:social tools for stable mw releases. [14:42:46] PROBLEM - Current Load on swift1 is WARNING: WARNING - load average: 3.60, 3.29, 2.95 [14:44:46] RECOVERY - Current Load on swift1 is OK: OK - load average: 2.79, 3.05, 2.90 [15:07:43] [02miraheze/CreateWiki] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNkA4 [15:07:45] [02miraheze/CreateWiki] 07paladox 03654e0e5 - Change o to 0 [15:07:47] JohnLewis ^^ [15:09:02] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNkAV [15:09:04] [02miraheze/mediawiki] 07paladox 039483f6d - Update CreatePage [15:09:48] !log sudo -u www-data php /srv/mediawiki/w/maint*/rebuildLocalisationCache.php --wiki test1wiki on mw* [15:09:52] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [15:11:26] uh [15:11:29] i did the wrong ext [15:11:30] meh [15:12:19] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNkxJ [15:12:21] [02miraheze/mediawiki] 07paladox 035db2e7e - Update CreateWiki [15:20:10] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNkxF [15:20:12] [02miraheze/mediawiki] 07paladox 035dca27a - Update DynamicPageList3 [15:23:27] RECOVERY - Puppet on mw3 is OK: OK: Puppet is currently enabled, last run 34 seconds ago with 0 failures [15:25:27] RECOVERY - Puppet on mw1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [15:39:11] [02miraheze/mediawiki] 07paladox pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNkji [15:39:13] [02miraheze/mediawiki] 07paladox 03229bbe2 - Update DynamicPageList3 [15:52:26] PROBLEM - JobQueue on mw3 is CRITICAL: JOBQUEUE CRITICAL - job queue greater than 300 jobs. Current queue: 2659 [17:17:28] RECOVERY - Puppet on test1 is OK: OK: Puppet is currently enabled, last run 2 minutes ago with 0 failures [17:21:49] !log rm -rf /srv/mediawiki on test1 [17:21:52] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [17:25:28] PROBLEM - Puppet on test1 is CRITICAL: CRITICAL: Catalog fetch fail. Either compilation failed or puppetmaster has issues [17:30:10] MacFan4000: uh I forgot, what was that page that listed all the pages that need to be marked as translations? [17:30:34] Reception123: Special:PageTranslation [17:30:43] yeah, thanks :) [17:33:26] PROBLEM - MediaWiki Rendering on test1 is CRITICAL: HTTP CRITICAL: HTTP/1.1 500 MediaWiki configuration Error - 1272 bytes in 0.022 second response time [17:33:40] Notice: Applied catalog in 583.50 seconds [17:33:44] paladox: here's our timeout [17:33:54] ok [17:40:07] [02miraheze/mw-config] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNI3U [17:40:08] [02miraheze/mw-config] 07paladox 038dae5ce - Change wmgUseEditCount to wmgUseEditcount [17:40:10] Reception123 ^^ [17:40:24] ok great :) [17:40:25] thanks [17:41:14] Error: /Stage[main]/Mediawiki/Git::Clone[MediaWiki core]/Exec[git_pull_MediaWiki core]/returns: change from notrun to 0 failed: Command exceeded timeout [17:41:17] ^ paladox this happens [17:41:25] but then when I git pull in /w it says "already up to date" [17:41:26] hmm [17:41:30] Reception123 yeh [17:41:35] test1 does not have enough cores [17:41:40] to do it within the timeout period [17:41:44] Warning: /Stage[main]/Mediawiki::Extensionsetup/Exec[Math texvccheck]: Skipping because of failed dependencies [17:41:55] paladox: yeah, but I already did git pull manually [17:41:55] Reception123 rm -rf /srv/mediawiki/w [17:42:13] ok [17:42:18] git clone -b REL1_31 https://github.com/miraheze/mediawiki.git w --recursive [17:42:18] Title: [ GitHub - miraheze/mediawiki: The collaborative editing software that runs Wikipedia. ] - github.com [17:42:57] PROBLEM - Current Load on test1 is CRITICAL: CRITICAL - load average: 2.79, 2.13, 1.34 [17:43:17] paladox: haha by accidentally writing w instead of "cd w" I discovered a new command [17:43:27] PROBLEM - MediaWiki Rendering on test1 is WARNING: HTTP WARNING: HTTP/1.1 404 Not Found - 199 bytes in 0.028 second response time [17:43:31] lol Reception123 what new command? [17:43:35] w :P [17:44:56] Reception123 oh w is not a command [17:44:57] that's the path [17:44:57] PROBLEM - Current Load on test1 is WARNING: WARNING - load average: 1.35, 1.80, 1.32 [17:45:39] paladox: no, try it :D [17:45:48] oh -w? [17:45:50] no [17:45:50] just w [17:45:58] git clone -b REL1_31 https://github.com/miraheze/mediawiki.git w --recursive [17:45:59] Title: [ GitHub - miraheze/mediawiki: The collaborative editing software that runs Wikipedia. ] - github.com [17:46:00] ? [17:46:03] w --recursive? [17:46:06] Reception123 ^^ [17:46:20] https://www.irccloud.com/pastebin/zvas12j5/ [17:46:22] Title: [ Snippet | IRCCloud ] - www.irccloud.com [17:46:22] ^ paladox [17:46:23] type fucking w paladox in shel [17:46:32] ll [17:46:39] it's that easy :D [17:46:57] RECOVERY - Current Load on test1 is OK: OK - load average: 1.04, 1.53, 1.27 [17:47:16] oh [17:47:21] https://www.irccloud.com/pastebin/loodl7Df/ [17:47:22] Title: [ Snippet | IRCCloud ] - www.irccloud.com [17:47:23] i thought he was talking about git JohnLewis [17:47:30] I was just scrolling back to find something and then I see that [17:47:38] ^ paladox [17:47:43] uh [17:48:06] It reveals who is logged in, and also their IP [17:48:42] and load avg + uptime [17:48:53] for each user [17:48:58] but uptime does this too [17:49:02] yeah [17:49:30] echo "Reception123 test" | wall [17:49:43] Reception123 try that :D [17:50:02] heh [17:50:05] there must be many of these commands [17:50:17] .mangle [17:50:24] MacFan4000: Acceptance 123 says that "many of these directives are worthy" [17:50:25] MacFan4000: I just recieved email saying that my request (T3336) went from resolved to declined. When checking Special:ManageWiki I see that the (succesful) changes from yesterday were rolled back. [17:50:52] Not me, rather JohnLewis to blame [17:51:00] Fritigern: Hi. Unfortunately, the changes were not successful as many of the extensions did not work with the links. [17:51:09] JohnLewis didn't decline the task, he reverted the change as it broke other things [17:51:27] Most of them worked and some had name conflicts [17:51:28] It is possible that this could be done sometime in the future, but since it doesn't work very well now, it was decided that it will be declined [17:51:40] Yeah, but we can't have most working and not some [17:51:48] unless we could somehow modify those manually [17:51:57] We should do it right [17:52:02] It wasn’t breaking anything paladox those were only warnings [17:52:03] otherwise it's just hacks [17:52:03] on top of hacks [17:52:13] The question is why some did not work [17:52:15] MacFan4000: yeah, but we don't want some of the links not to work [17:52:24] I think it was your change that broke it paladox [17:52:24] MacFan4000 they were log spam and also JohnLewis said it didn't work correctly. [17:52:29] i didn't check my self. [17:52:39] MacFan4000 um your change broke it [17:52:48] if it was producing that amount of log spam [17:52:51] in the first place [17:53:02] It was good that some of them worked, but all of them working is what we want to achieve. [17:53:16] As I said before, anyone is free to pick up the task again [17:53:20] I think your change made the extension unusable [17:53:56] I think that this may be a case of "too many cooks spoil the soup" [17:54:06] I never broke anything except links [17:54:14] MacFan4000: which change? [17:54:16] MacFan4000 still it caused the log spam sooo my change may have broke it [17:54:27] but i do not want the logs to be spammed hiding other stuff. [17:54:33] Stop bickering. Be professional. [17:54:42] ^^ [17:54:46] There's no need to get into a "who's change broke more" discussion here :P [17:55:10] Whatever the changes were, the current version is the stable one and the one that works properly. [17:55:56] The re4al question is not "who proke it" but "why do most links work and some don't?" as well as "how can the logspam be pevented?". [17:56:25] i think the way to resolve this is to add a linkPage param [17:56:40] so that when defined it adds the links to that ext which defined it. [17:58:07] ^ was my plan and my cha change that was ignored [17:58:27] the label-message parameter is i18n string and parameter, and label is raw only [17:59:29] Which is why I said we couldn’t do it [18:01:29] if we do ‘label-message’ => [‘managewiki-extension/skin-name’, $ext[‘linkPage’], $ext[‘name’]] I think it just may work [18:01:43] that will fail..... [18:01:43] Along with that if statement [18:01:53] yeh if statement [18:02:08] It’s i18n string followed by two parameters [18:02:38] 14:01 Along with that if statement [18:02:51] Actually no [18:03:50] Just do the parameter change, add i18n, and do a lot of changes in ManageWiki.php [18:04:04] I think it would work paladox [18:04:49] I think it's easier to just link [[M:Extensions]] rather than all this work [18:05:17] ^ that too I guess maybe? [18:05:45] Everything is linked there, so that's a great page people can consult to see extensions [18:06:00] That’s not always up to date though [18:07:14] Well we could just remember to update when installing an extension [18:07:30] It's easier than making a complicated edit to MW [18:08:33] At this point what I am saying, means changing two lines in one file adding two in another and a bunch in mw-config [18:09:11] If you can make it work. Then do it [18:09:45] My close yesterday on the task was basically a “Ive done this if someone does x” and my x is what you’re suggesting [18:10:35] The task is done either way as I did it yesterday in a different way pending upstream [18:17:24] also, everything in /srv/mediawiki/w on test1 is owned by root, can someone please fix that? [18:17:32] Otherwise I can't edit [18:18:28] geez 9.9k jobs [18:19:17] oh, uh, nvm, I see that people are still doing stuff [18:21:44] yeah puppet is failing because of perms, so ops needs to change the perms on /srv/mediawiki/w [18:22:58] Reception123: ^ your fault [18:23:56] Notice: /Stage[main]/Mediawiki/Git::Clone[MediaWiki core]/Exec[git_pull_MediaWiki core]/returns: error: cannot open .git/FETCH_HEAD: Permission denied [18:24:04] Yeah, though test1 is meant for testing [18:24:20] No access atm, paladox can you chown ^ [18:24:25] well, anyway thats why puppet is failing [18:24:32] Yeah [18:26:27] Reception123 still, tsk tsk! [18:28:54] the folder itself is owned by www-data, but its contents are owned by root [18:30:11] When I was mw-admins people left files owned by root so [18:30:12] .. [18:30:22] But yeah should've done www-data [18:30:33] Reception123 Where? [18:30:53] /srv/mediawiki/w [18:31:00] Reception123 i ment which server? [18:31:08] test1 paladox [18:31:10] ok [18:31:11] thanks [18:31:34] done [18:31:35] fixed [18:32:04] Reception123: hush, I did what I want back then okay because it was mostly be doing it anyway xD [18:32:38] JohnLewis huh? [18:33:16] Paladox: nothing [18:33:32] ok [18:33:52] paladox: 14:30 <+Reception123> When I was mw-admins people left files owned by root so [18:34:19] oh o [18:34:21] ok [18:39:27] RECOVERY - Puppet on test1 is OK: OK: Puppet is currently enabled, last run 25 seconds ago with 0 failures [18:41:27] PROBLEM - MediaWiki Rendering on test1 is CRITICAL: HTTP CRITICAL: HTTP/1.1 500 Internal Server Error - 624 bytes in 0.365 second response time [18:42:51] !log macfan@test1:/srv/mediawiki/w/maintenance$ sudo -u www-data php rebuildLocalisationCache.php --wiki test1wiki [18:42:55] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [18:52:58] PROBLEM - Current Load on test1 is WARNING: WARNING - load average: 1.75, 1.56, 1.04 [18:56:56] PROBLEM - Current Load on test1 is CRITICAL: CRITICAL - load average: 2.34, 1.86, 1.27 [18:58:56] RECOVERY - Current Load on test1 is OK: OK - load average: 1.41, 1.68, 1.27 [18:59:26] PROBLEM - Puppet on test1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Exec[git_pull_MediaWiki core] [19:01:00] 8k jobs [19:01:05] This is annoying now [19:04:09] JohnLewis add more runners [19:05:14] The job runner isn’t the issue [19:05:39] Overpowering stuff because of inefficiency is always bad [19:07:27] RECOVERY - Puppet on test1 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [19:09:27] RECOVERY - MediaWiki Rendering on test1 is OK: HTTP OK: HTTP/1.1 200 OK - 30105 bytes in 0.971 second response time [19:47:30] paladox: https://meta.miraheze.org/w/index.php?diff=54695&oldid=54660&rcid=143524 [19:47:32] Title: [ Difference between revisions of "Stewards' noticeboard" - Miraheze Meta ] - meta.miraheze.org [19:47:52] * paladox looks [19:48:41] JohnLewis fixed [19:48:47] !log swift post -r '.r:*' jawp2chwiki-mw [19:48:51] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [19:49:43] Kay [19:59:30] You haven’t replied to the user btw paladox [20:00:04] JohnLewis done [20:03:26] PROBLEM - Puppet on test1 is WARNING: WARNING: Puppet is currently disabled, message: reason not specified, last run 8 minutes ago with 0 failures [20:07:11] Not specified? Who disabled it? ^^ [20:07:26] PROBLEM - MediaWiki Rendering on test1 is CRITICAL: HTTP CRITICAL: HTTP/1.1 500 Internal Server Error - 222 bytes in 0.045 second response time [20:08:24] JohnLewis not me [20:10:55] [11-Jul-2018 20:10:48 Etc/Utc] PHP Parse error: syntax error, unexpected ':', expecting ')' in /srv/mediawiki/config/ManageWiki.php on line 6 [20:11:16] someone touched it at -rw-r--r-- 1 www-data www-data 32K Jul 11 20:04 /srv/mediawiki/config/ManageWiki.php [20:11:21] Its me [20:12:07] In general for all then: when disabling puppet, provide a reason please. Even your name is enough please. [20:12:48] MacFan4000 they are all in literels [20:12:51] should be '' [20:13:17] well it's test server [20:13:23] so im going back to socialprofile [20:18:53] acc'd working on it [20:19:04] s/acc/ack [20:19:05] MacFan4000 meant to say: ack'd working on it [20:49:58] paladox: ^^ I'm still seeing the same error, but I replaced ' with " [20:50:08] hmm [20:50:30] i can still see the problems in ManageWiki.php [20:50:33] vi highlighting off [20:50:39] indicating syntax error [20:50:48] what [20:50:56] Also I use nano and not vi/vim [20:51:31] paladox: ^^ [20:51:46] MacFan4000 huh, is your keyboard set funny? [20:52:28] uh [20:52:37] PROBLEM - MediaWiki Rendering on mw3 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [20:52:48] I don't understand what the syntax error is [20:53:27] PROBLEM - Varnish Backends on cp5 is CRITICAL: 2 backends are down. mw1 mw2 [20:53:47] PROBLEM - GDNSD Datacenters on misc1 is CRITICAL: CRITICAL - 6 datacenters are down: 107.191.126.23/cpweb, 2604:180:0:33b::2/cpweb, 81.4.109.133/cpweb, 2a00:d880:5:8ea::ebc7/cpweb, 172.104.111.8/cpweb, 2400:8902::f03c:91ff:fe07:444e/cpweb [20:53:51] um [20:53:55] why is mw* down [20:53:57] PROBLEM - Current Load on misc4 is CRITICAL: CRITICAL - load average: 4.89, 3.24, 1.70 [20:54:07] PROBLEM - MediaWiki Rendering on mw2 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [20:54:12] uh crap [20:54:27] PROBLEM - Varnish Backends on cp2 is CRITICAL: 1 backends are down. mw2 [20:55:07] timed out [20:55:18] is it because of increased traffic? [20:55:27] RECOVERY - Varnish Backends on cp5 is OK: All 3 backends are healthy [20:55:44] 16:52 <+MacFan4000> I don't understand what the syntax error is [20:55:47] RECOVERY - GDNSD Datacenters on misc1 is OK: OK - all datacenters are online [20:55:51] We have increased traffic?? Didn’t know a World Cup exit could do that [20:55:55] lol [20:56:01] MacFan4000 it's fixed now [20:56:11] MacFan4000 but yes invalid syntax [20:56:16] `` is not a string [20:56:20] that is literels [20:56:26] i may have misplet it [20:56:27] RECOVERY - HTTP 4xx/5xx ERROR Rate on cp4 is OK: OK - NGINX Error Rate is 10% [20:56:34] and same goes for the back ticks. [20:56:48] JohnLewis i am throwing out ideas :) [20:56:49] but I replaced " with ' [20:56:53] but it is timing out [20:56:55] in php-fpm [20:57:11] meaning in creased connection (i got that from #wikimedia-operations) [20:57:12] today! [20:57:21] MacFan4000 for some you didn't do them all [20:57:28] maybe it's your client? [20:57:52] https://test1.miraheze.org/wiki/Special:ManageWiki [20:57:53] Title: [ Internal error - Test1 Wiki ] - test1.miraheze.org [20:57:55] parse error anyways [20:57:58] Or its just me missing some by mistake? :P [20:58:46] !log restarted php7.2-fpm on mw2 [20:58:50] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [20:59:32] /wiki/Special:ManageWiki ParseError from line 154 of /srv/mediawiki/w/extensions/ManageWiki/includes/SpecialManageWiki.php: syntax error, unexpected ''default'' (T_CONSTANT_ENCAPSED_STRING), expecting ')' [20:59:37] MacFan4000 ^^ [20:59:58] RECOVERY - MediaWiki Rendering on mw2 is OK: HTTP OK: HTTP/1.1 200 OK - 30102 bytes in 0.091 second response time [21:00:06] MacFan4000 uh yeh it's your client [21:00:10] RECOVERY - GDNSD Datacenters on ns1 is OK: OK - all datacenters are online [21:00:11] literels again [21:00:28] RECOVERY - Varnish Backends on cp2 is OK: All 3 backends are healthy [21:02:00] ack'd [21:03:12] fixed https://test1.miraheze.org/wiki/Special:ManageWiki [21:03:13] Title: [ Permission error - Test1 Wiki ] - test1.miraheze.org [21:03:19] it's very slow tonight [21:03:22] test1 [21:03:22] ssh [21:05:26] PROBLEM - Puppet on mw2 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Exec[git_pull_MediaWiki core] [21:05:28] PROBLEM - Puppet on mw1 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 2 minutes ago with 1 failures. Failed resources (up to 3 shown): Exec[git_pull_MediaWiki core] [21:05:29] And on wiki i18n now created [21:05:39] so, now just correct a few urls, and done [21:06:27] ⧼managewik-skin-name⧽ [21:06:33] MacFan4000 remember to check the logs [21:06:34] too [21:06:38] when saving [21:13:08] [02miraheze/puppet] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIVQ [21:13:10] [02miraheze/puppet] 07paladox 038dcf43d - Increasing php-fpm resources Will revert this if it has a negative impact. [21:13:10] JohnLewis ^^ [21:13:37] for incrased demand! (i have no proof that it's increased demand) we should probaley have grafana have a dashboard for traffic. [21:17:27] RECOVERY - Puppet on mw1 is OK: OK: Puppet is currently enabled, last run 8 seconds ago with 0 failures [21:23:27] RECOVERY - Puppet on mw3 is OK: OK: Puppet is currently enabled, last run 42 seconds ago with 0 failures [21:26:28] [02miraheze/puppet] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIrT [21:26:29] [02miraheze/puppet] 07paladox 033fbce07 - Update jobrunner.json.erb [21:28:17] paladox: why? [21:28:24] More unnecessary load [21:28:34] JohnLewis because 2 for the amout of wiki's we have is low [21:28:44] i can revert if you want? [21:29:51] There isn’t an issue 99% of the time [21:29:57] ok [21:30:50] [02miraheze/puppet] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIr6 [21:30:51] [02miraheze/puppet] 07paladox 033cc3b5a - Revert "Update jobrunner.json.erb" This reverts commit 3fbce071b552b4b26ff277aacdde9a01a8ca841c. [21:30:54] JohnLewis done ^^ [21:31:08] It’ll just compete with memory for php meaning mw3 becomes our bottle neck server [21:33:00] we could do that and re-make mw2 a job runner? [21:34:34] [02miraheze/mw-config] 07paladox pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIof [21:34:36] [02miraheze/mw-config] 07paladox 037629b48 - Reorganise mscalendar [21:34:48] No [21:43:56] JohnLewis: was that to me or paladox? [21:44:11] you [21:44:15] ok [21:44:43] also thinking about it, your change should handle no url being given [21:44:54] ^^ [21:45:12] that's why i said if the param is defined (so optional that you can have a url) [21:48:49] don't quite know how to do that [21:49:16] but, per "You can deploy if it works", I am going to deploy [21:49:18] that's fine then [21:49:31] I can get around to it at some point when I audit the extensions anyway [21:49:42] ok [21:49:44] JohnLewis yay for audits! [21:49:45] jk [21:50:40] paladox: extra children means extra load [21:50:54] Remember my comment about amount of children = amount of cores [21:50:57] SPF|Cloud i guess so, but better then mw* being depooled [21:51:16] Excessive load is even worse [21:51:21] hmm right [21:51:47] but then when a mw is depooled the load shifts [21:51:49] to another mw [21:51:50] More children are preferred I know, but we need more cores for that [21:52:03] but worse the mw will have more load as more traffic will hit it. [21:52:07] SPF|Cloud we have 4 though? [21:52:12] Yes [21:52:17] And children is set to 4 [21:52:36] SPF|Cloud what if i set max requests to 1,000 and children back down to what you set? [21:52:40] would that work? [21:53:17] You could set it to 1000 but at our request rate said impact is likely invisible [21:53:38] something is causing instability though. [21:53:47] mw2 was depooled from cp5 earlier [21:54:01] that could just be latency [21:54:02] and cp2 [21:54:06] ah [21:54:45] You are free to perform tests with different kind of php-fpm settings, just want to let you know it's set to 4 for a reason [21:55:39] SPF|Cloud ok, i am going to revert then and increase requests then. [21:55:46] SPF|Cloud could i also upp https://github.com/miraheze/puppet/blob/master/modules/varnish/templates/default.vcl#L26 ? [21:55:46] Title: [ puppet/default.vcl at master · miraheze/puppet · GitHub ] - github.com [21:55:49] (timeout to 10s) [21:56:15] That does not fix the underlying issue but sure.. [21:56:22] though https://grafana.miraheze.org/d/W9MIkA7iz/miraheze-cluster?orgId=1&var-job=node&var-node=mw2.miraheze.org&var-port=9100 looks fine (load wise) [21:56:22] Title: [ Grafana ] - grafana.miraheze.org [21:57:05] SPF|Cloud ^^ [21:57:34] It's either latency or too many concurrent requests [21:57:48] hmm yeh [21:58:04] I could imagine php-fpm getting too many requests [21:58:04] SPF|Cloud so upping the request max and putitng max child back at what you set will work? [21:58:07] just making sure. [21:58:09] [02miraheze/ManageWiki] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIKx [21:58:10] yeh [21:58:10] [02miraheze/ManageWiki] 07MacFan4000 03a9d7401 - ManageWiki extension links [21:58:24] Raising children could fix that, but also means load will go through the roof [21:58:56] [02miraheze/puppet] 07paladox pushed 032 commits to 03master [+0/-0/±2] 13https://git.io/fNI6v [21:58:58] [02miraheze/puppet] 07paladox 032217f7a - Revert "Increasing php-fpm resources" This reverts commit 8dcf43d087a38220b9f8e56995a51bb656b848bf. [21:58:59] [02miraheze/puppet] 07paladox 034718acd - php-fpm: set pm.max_requests to 1000 [21:59:02] SPF|Cloud ^^ [21:59:11] SPF|Cloud well i only increased max child by 1 [21:59:19] but reverted now. [21:59:26] And in the worst scenario the server will be overloaded anyways and RamNode will shut it down at some point resulting in complete unavailability [21:59:50] Where the same will happen with other servers and then.. yeah, don't need to explain that [21:59:50] hmm ok [21:59:54] [02miraheze/ManageWiki] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNI6U [21:59:56] [02miraheze/ManageWiki] 07MacFan4000 030e7163f - i18n [22:00:51] SPF|Cloud ok thanks for explaining! i wont increase the childs then. I've increased max requests. [22:01:19] never increase the children. who needs children anyway [22:01:39] JohnLewis lol, are you talking about nginx? Or personal experence :D [22:01:47] Hehe [22:01:53] definitely not personal experience xD [22:01:54] Oh right, nginx is also running on those servers [22:03:17] JohnLewis heh [22:03:28] it must be your job getting at your! [22:03:51] *you not your [22:04:02] now that's my job getting at me [22:04:19] huh [22:04:38] JohnLewis ? [22:04:50] [02miraheze/mediawiki] 07MacFan4000 pushed 031 commit to 03REL1_31 [+0/-0/±1] 13https://git.io/fNI6o [22:04:52] [02miraheze/mediawiki] 07MacFan4000 030fbae09 - Update mw [22:05:04] massive your, you're and you campaign as well as there, their and they're [22:05:16] paladox: what about moving php-fpm to static children? [22:05:33] SPF|Cloud hmm. Arn't we using static? [22:05:40] what about moving php-fpm to the bin and just making HTML static pages? :P [22:05:49] dynamic [22:06:00] Or what about fixing varnish' hit rate [22:06:01] https://github.com/miraheze/puppet/blob/master/modules/mediawiki/files/php/www-7.2.conf#L14 [22:06:02] Title: [ puppet/www-7.2.conf at master · miraheze/puppet · GitHub ] - github.com [22:06:04] SPF|Cloud ^^ [22:06:20] JohnLewis lol that would be far tooooo basiccccc [22:06:22] Oh heh.. I'm getting old I guess :P [22:06:48] Our cache hit rate is 4.6%!? [22:06:58] [02miraheze/mw-config] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNI6H [22:06:59] [02miraheze/mw-config] 07MacFan4000 033fa1137 - mw config [22:06:59] https://haydenjames.io/php-fpm-tuning-using-pm-static-max-performance/ [22:07:01] Title: [ PHP-FPM tuning: Using 'pm static' for max performance ] - haydenjames.io [22:07:20] SPF|Cloud really? I wonder how we improve the cache rate..... [22:08:41] Past experience says most of our users are logged in [22:09:38] SPF|Cloud shoulden't we be caching if they are logged in? [22:10:04] No? Otherwise you can't see dynamic pages [22:10:05] I mean, we are hosting a lot of editing based wikis, we're not exactly a top 5 encyclopedia where most people go to check a fact for their school essay [22:10:19] heh [22:10:37] In that case you couldn't log in, use custom css/js, change your preferences, distinguish between anonymous users and sysops, etc [22:11:05] SPF|Cloud so about the static child, does that mean we can upp it? [22:11:10] see https://haydenjames.io/php-fpm-tuning-using-pm-static-max-performance/ [22:11:10] Title: [ PHP-FPM tuning: Using 'pm static' for max performance ] - haydenjames.io [22:11:24] Wikimedia actually has a really high hit rate, as in amazing, but still needs many servers for editors [22:12:13] We don't have a high hit rate (John's comment is true) so need even more servers for the same amount of users [22:12:38] !log sudo -u www-data php rebuildLocalisationCache.php --wiki test1wiki [22:12:42] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [22:12:46] !log on mw* [22:12:50] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [22:13:31] SPF|Cloud https://info.varnish-software.com/blog/high-hit-rate-with-varnish [22:13:31] https://phabricator.wikimedia.org/T106099 this is actually a good solution for our problem though. Less backend load [22:13:31] Title: [ Achieving a high cache hit rate with Varnish ] - info.varnish-software.com [22:13:33] Title: [ ⚓ T106099 RFC: Page composition using service workers and server-side JS fall-back ] - phabricator.wikimedia.org [22:14:17] Meh, could increase the hit rate with a few percent but nothing shocking. Our user base does not primarily consist of readers. [22:15:45] Seperate load.php for each wiki and user (anon/registered) isn't helping either, but I recalled there has been some progress in that area [22:17:54] https://www.fastly.com/blog/common-causes-poor-cache-hit-ratio-and-how-deal-them [22:17:54] Title: [ Common causes of a poor cache hit ratio and how to deal with them ] - www.fastly.com [22:17:58] SPF|Cloud there's ^^ [22:18:36] Those pages don't contain anything I didn't knew yet [22:19:59] you can't dynamic stuff soo [22:20:06] static.miraheze.org is not cached, but luckly swift does with memcached. [22:20:17] static should be cached actually [22:20:27] plus some extensions implement use of nocache [22:20:30] JohnLewis SPF|Cloud https://phabricator.miraheze.org/T3343 [22:20:31] Title: [ ⚓ T3343 Error 503 Backend fetch failed ] - phabricator.miraheze.org [22:21:46] With our user base, improving hit rate more than a few percent is just impossible until T106099 will be implemented [22:22:12] So; I would rather focus on our backend instead of frontend, as it seems things are going wrong at the backend side [22:22:32] ok [22:22:45] which is the backend? [22:22:46] mw* [22:22:48] ? [22:23:18] Yes [22:23:25] ok [22:23:47] PROBLEM - Current Load on swift1 is CRITICAL: CRITICAL - load average: 4.05, 3.76, 3.19 [22:24:28] SPF|Cloud im sure that if varnish detects static.m.org is down due to swift problems it depools. [22:24:33] (though not 100% sure) [22:24:46] we really need to fix varnish to not depool if static.m.org is down) [22:25:47] RECOVERY - Current Load on swift1 is OK: OK - load average: 2.73, 3.34, 3.10 [22:26:24] If the 503 errors are because of backend lockups, we should invest in extra cpu cores (= more servers) [22:26:59] However looking at our average cpu usage that would be a waste of money, difficult... [22:29:09] Could you look if we use opcache efficiently? [22:29:47] PROBLEM - Current Load on swift1 is CRITICAL: CRITICAL - load average: 4.89, 3.99, 3.39 [22:31:34] SPF|Cloud well we have it enabled but not the setting that would improve performance [22:31:44] ie it checks the php file everytime there is a request [22:32:00] which would need to stay enabled i guess as we change things frequent. [22:32:42] Response time is rather low though, especially with the new php version [22:33:12] yeh, but php-fpm can timeout on mw* [22:33:28] which i have no idea why [22:33:40] Perhaps the problem is caused by users visiting slow wikis? [22:33:49] some ideas are more traffic or not enough child. [22:33:56] SPF|Cloud ah yeh could be [22:33:59] Where it takes way too long to parse the pages, resulting in a lock up [22:34:32] yeh [22:34:47] but i have no idea how it can be slowwwww [22:40:58] PROBLEM - Current Load on swift2 is WARNING: WARNING - load average: 3.77, 3.22, 2.28 [22:42:36] NRPE: Command 'check_bacula_static' not defined [22:42:56] paladox: I assume that needs to be removed from icinga? [22:42:56] RECOVERY - Current Load on swift2 is OK: OK - load average: 3.01, 3.04, 2.32 [22:43:01] yep [22:43:28] Can you please do that then? [22:43:36] in /srv/mediawiki/w we have 17859 php files but only 2352 are cached according to opcache status [22:44:09] done [22:44:13] you would say that is a problem, but opcache_hit_rate is 99.94%.. [22:44:27] Thanks [22:45:06] SPF|Cloud cp5 "RITICAL - NGINX Error Rate is 77%" [22:45:08] CRITICAL - NGINX Error Rate is 77% [22:45:10] in icinga [22:46:04] investigate that [22:46:26] PROBLEM - HTTP 4xx/5xx ERROR Rate on cp5 is WARNING: WARNING - NGINX Error Rate is 48% [22:48:26] RECOVERY - HTTP 4xx/5xx ERROR Rate on cp5 is OK: OK - NGINX Error Rate is 22% [22:51:15] I don’t see that [22:51:21] it recovered [22:56:04] [02miraheze/mw-config] 07MacFan4000 pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNIXp [22:56:06] [02miraheze/mw-config] 07MacFan4000 0369d72f4 - remove domain that is no longer pointed to us [22:56:35] revalidate_freq seems to be an interesting parameter [22:57:57] To my knowledge it currently takes one second before changes to MediaWiki code will actually be applied. By setting revalidate_freq to five the load will likely decrease, but it will also take five seconds before changes will be applied. Is that feasible? [22:58:57] SPF|Cloud yeh guess soo [23:00:18] [02miraheze/puppet] 07Southparkfan pushed 031 commit to 03master [+0/-0/±1] 13https://git.io/fNI1m [23:00:20] [02miraheze/puppet] 07Southparkfan 03d210538 - Change some opcache parameters [23:00:23] [02ssl] 07MacFan4000 opened pull request 03#41: Remove cert for domain that is no longer pointed to us - 13https://git.io/fNI1O [23:01:24] paladox: ^^ [23:01:25] [02ssl] 07paladox closed pull request 03#41: Remove cert for domain that is no longer pointed to us - 13https://git.io/fNI1O [23:01:27] [02miraheze/ssl] 07paladox pushed 031 commit to 03master [+0/-1/±1] 13https://git.io/fNI1G [23:01:28] [02miraheze/ssl] 07MacFan4000 0347de44d - Remove cert for domain that is no longer pointed to us (#41) * Update certs.yaml * Delete wiki.pablojprieto.com.es.crt [23:01:33] thanks [23:05:28] RECOVERY - Puppet on test1 is OK: OK: Puppet is currently enabled, last run 2 minutes ago with 0 failures [23:06:27] paladox: db4 has low space again [23:06:34] yep [23:06:40] 70+gb [23:07:24] Perhaps purge logs again? [23:07:35] yeh later [23:07:41] dealing with other stuff. [23:08:13] Ok [23:09:48] PROBLEM - Current Load on swift1 is WARNING: WARNING - load average: 3.49, 3.78, 3.99 [23:16:32] RECOVERY - JobQueue on mw3 is OK: JOBQUEUE OK - job queue below 300 jobs [23:17:42] PROBLEM - Current Load on swift1 is CRITICAL: CRITICAL - load average: 4.02, 3.41, 3.66 [23:19:42] PROBLEM - Current Load on swift1 is WARNING: WARNING - load average: 3.35, 3.38, 3.62 [23:20:35] tbh 70G isn't "low space" [23:20:52] given the average DB growth [23:21:23] 72G out of 377G, not as critical as it used to be [23:22:03] oh wait [23:22:07] I think I have a trick [23:23:23] ha [23:24:07] remember my mail regarding a very large mysql log file that was actually deleted but df -h would still see it as an existing file? [23:25:26] !log cleared a mysql log file with :>/proc/1614/fd/442 [23:25:30] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [23:25:40] 49G cleared ;) [23:26:15] 239G in use, 119G free, 67% free. that's better eh? [23:26:33] RECOVERY - Disk Space on db4 is OK: DISK OK - free space: / 121828 MB (33% inode=95%): [23:56:20] !log created /srv/mediawiki/opcache.php on mw1, will be removed soon (not worth puppetising), only contains non-private opcache information [23:56:25] Logged the message at https://meta.miraheze.org/wiki/Tech:Server_admin_log, Master [23:57:23] PROBLEM - Puppet on swift1 is WARNING: WARNING: Puppet is currently disabled, message: paladox, last run 6 minutes ago with 0 failures