[00:56:45] ACKNOWLEDGEMENT - High lag on wdqs2005 is CRITICAL: 8639 ge 3600 Stas Malychev db reload, will catch up soon https://grafana.wikimedia.org/dashboard/db/wikidata-query-service?orgId=1&panelId=8&fullscreen [01:02:25] !log repooled wdqs200[45] for now, 2006 still not done, will get to it later today [01:02:25] SMalyshev: Not expecting to hear !log here [01:02:25] El búfer 45 está vacío. [01:52:17] RECOVERY - High lag on wdqs2004 is OK: (C)3600 ge (W)1200 ge 1094 https://grafana.wikimedia.org/dashboard/db/wikidata-query-service?orgId=1&panelId=8&fullscreen [01:57:22] i wonder if the mix'n'match catalogs are updated at all? [01:58:02] i mean, people are manually adding a lot of properties to items, how does mix'n'match take care of that? [01:58:25] RECOVERY - High lag on wdqs2005 is OK: (C)3600 ge (W)1200 ge 976 https://grafana.wikimedia.org/dashboard/db/wikidata-query-service?orgId=1&panelId=8&fullscreen [06:04:55] PROBLEM - Check systemd state on wdqs2005 is CRITICAL: CRITICAL - degraded: The system is operational but one or more units failed. [06:06:11] PROBLEM - Blazegraph process -wdqs-blazegraph- on wdqs2006 is CRITICAL: PROCS CRITICAL: 0 processes with UID = 499 (blazegraph), regex args ^java .* --port 9999 .* blazegraph-service-.*war [06:06:15] PROBLEM - Check systemd state on wdqs2006 is CRITICAL: CRITICAL - degraded: The system is operational but one or more units failed. [06:06:25] PROBLEM - Blazegraph Port for wdqs-blazegraph on wdqs2006 is CRITICAL: connect to address 127.0.0.1 and port 9999: Connection refused [06:23:23] RECOVERY - Blazegraph process -wdqs-blazegraph- on wdqs2006 is OK: PROCS OK: 1 process with UID = 499 (blazegraph), regex args ^java .* --port 9999 .* blazegraph-service-.*war [06:23:35] RECOVERY - Blazegraph Port for wdqs-blazegraph on wdqs2006 is OK: TCP OK - 0.000 second response time on 127.0.0.1 port 9999 [09:06:41] PROBLEM - High lag on wdqs2006 is CRITICAL: 1.101e+04 ge 3600 https://grafana.wikimedia.org/dashboard/db/wikidata-query-service?orgId=1&panelId=8&fullscreen [09:17:35] PROBLEM - Disk space on wdqs2006 is CRITICAL: DISK CRITICAL - free space: /srv 53055 MB (3% inode=99%) [09:32:25] RECOVERY - Disk space on wdqs2006 is OK: DISK OK [09:34:21] PROBLEM - WDQS HTTP Port on wdqs2006 is CRITICAL: HTTP CRITICAL: HTTP/1.1 502 Bad Gateway - 380 bytes in 0.000 second response time [09:34:59] PROBLEM - Blazegraph process -wdqs-blazegraph- on wdqs2006 is CRITICAL: PROCS CRITICAL: 0 processes with UID = 499 (blazegraph), regex args ^java .* --port 9999 .* blazegraph-service-.*war [09:35:05] PROBLEM - Blazegraph Port for wdqs-blazegraph on wdqs2006 is CRITICAL: connect to address 127.0.0.1 and port 9999: Connection refused [09:52:45] RECOVERY - WDQS HTTP Port on wdqs2006 is OK: HTTP OK: HTTP/1.1 200 OK - 449 bytes in 0.646 second response time [09:53:23] RECOVERY - Blazegraph process -wdqs-blazegraph- on wdqs2006 is OK: PROCS OK: 1 process with UID = 499 (blazegraph), regex args ^java .* --port 9999 .* blazegraph-service-.*war [09:53:29] RECOVERY - Blazegraph Port for wdqs-blazegraph on wdqs2006 is OK: TCP OK - 0.000 second response time on 127.0.0.1 port 9999 [10:18:31] Wouldn't it make sense to have a separate channel for all icinga-wm stuff? [10:21:53] I assume it's relevant to a fairly small amount of wikidata users [10:26:49] there is a separate channel for notification bots which is already linked from the topic... no idea why it's using this one [10:28:10] If Wikidata is down, I wouldn't call the interested users to be a "fairly small amount" [10:29:56] sure but I don't think most people would know how to interpret those messages [10:30:19] I certainly can't [10:31:10] they seem designed for the maintainers, not the users [10:31:21] Yeah. Have it post here if WD is down with "WD IS DOWN!!!" and if it's back up with "WD IS BACK UP!!!!" and keep the rest elsewhere IMO [10:32:28] A message like "PROBLEM - High lag on wdqs" may not be the clearest possible but it's helpful for any users of wdqs who happens to check the channel when having problems [10:33:02] * reosarevok shrugs [10:33:11] You can just /ignore the bot if you are particularly affected by its messages [10:33:16] I just feel it gets in the way of actual humans talking about the project [10:33:36] I feel the opposite. Bots generally help spark conversations in freenode channels. [10:33:59] All the channels where bots have been removed ended up having less participation, not more. People followed the bots on other channels and the participation fragmented. [10:34:05] why did we move all the bots to another channel then? they used to be in here and it was annoying so they were moved [10:34:42] also how do I use /ignore on the logs to see actual conversation? [10:34:42] Maybe some bots were especially noisy, icinga-wm doesn't seem to be. [10:35:00] grep -v [10:35:25] so you're seriously suggesting I have to save the page and use the command line? [10:35:27] Most clients don't log the messages you ignore, AFAIK. [10:35:30] so user friendly... [10:35:38] "Save the page"? [10:35:53] http://wm-bot.wmflabs.org/browser/index.php?start=01%2F16%2F2019&end=01%2F16%2F2019&display=%23wikidata [10:36:20] Ah, the public logs. [10:42:12] I'm honestly not sure how many non-experts would even realize "wdqs" in the message means "the thing I use to query Wikidata", much less understand what the issue actually is, so I expect most people would still have to ask [10:42:26] Or they'd just assume their query timed out because it's asking too much [11:47:33] personally i assumed the errors that bot comes with occasionally i something that was related to dev ork on wikidata and not at all ever to me, as an user ffiw [11:48:09] so. i just igonre it. [11:48:30] 🤷 [11:49:39] (meaning it doesn't bother me, but then i have no use for it either) [14:52:03] ACKNOWLEDGEMENT - Check systemd state on wdqs2005 is CRITICAL: CRITICAL - degraded: The system is operational but one or more units failed. Gehel data transfer in progress [14:52:03] ACKNOWLEDGEMENT - Check systemd state on wdqs2006 is CRITICAL: CRITICAL - degraded: The system is operational but one or more units failed. Gehel data transfer in progress [15:20:35] RECOVERY - Check systemd state on wdqs2005 is OK: OK - running: The system is fully operational [15:28:39] RECOVERY - Check systemd state on wdqs2006 is OK: OK - running: The system is fully operational [15:50:57] Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @addshore & @CFisch_WMDE - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [16:41:40] http://ontologforum.org/index.php/ConferenceCall_2019_01_16 [16:42:01] starts in 15 minutes [16:49:26] looks like my question was missed to bot spam or nobody knows or nobody cares enough to answer XD [16:58:41] SothoTalKer_: if that's the question on mix'n'match, I can see it, so not option 1. probably option 2 then >< [16:59:38] i guess they still have to be manually matched, even if someone else already added the property [16:59:55] well, “don’t care” is not the only reason why someone may not answer… I for one simply have no idea :) [17:02:26] well, i also provided 2 other options, just pick the one that works best for you to identify with ;-) [17:03:21] i know some people here work with mix'n'match a bit, so why not ask, hehe :) [19:55:23] PROBLEM - WDQS SPARQL on wdqs1010 is CRITICAL: connect to address 10.64.32.63 and port 80: Connection refused [19:55:37] PROBLEM - Check systemd state on wdqs1010 is CRITICAL: CRITICAL - degraded: The system is operational but one or more units failed. [19:55:47] PROBLEM - WDQS HTTP on wdqs1010 is CRITICAL: connect to address 10.64.32.63 and port 80: Connection refused [19:56:09] PROBLEM - WDQS HTTP Port on wdqs1010 is CRITICAL: connect to address 127.0.0.1 and port 80: Connection refused [19:59:01] RECOVERY - WDQS SPARQL on wdqs1010 is OK: HTTP OK: HTTP/1.1 200 OK - 17141 bytes in 0.001 second response time [19:59:15] RECOVERY - Check systemd state on wdqs1010 is OK: OK - running: The system is fully operational [19:59:25] RECOVERY - WDQS HTTP on wdqs1010 is OK: HTTP OK: HTTP/1.1 200 OK - 17141 bytes in 0.001 second response time [19:59:49] RECOVERY - WDQS HTTP Port on wdqs1010 is OK: HTTP OK: HTTP/1.1 200 OK - 448 bytes in 0.017 second response time [21:55:45] RECOVERY - High lag on wdqs2006 is OK: (C)3600 ge (W)1200 ge 1059 https://grafana.wikimedia.org/dashboard/db/wikidata-query-service?orgId=1&panelId=8&fullscreen [22:40:24] Is there any way to filter https://www.wikidata.org/w/index.php?title=Special:Contributions/QuickStatementsBot&limit=500&target=QuickStatementsBot to see only one batch? [22:44:00] (I want to see what the hell I did, since I don't exactly know what the bot does :p [22:44:00] ) [22:44:25] And https://tools.wmflabs.org/sourcemd/?action=batch&batch=5440 seems to only show what did *not* work [22:48:12] greetings to you, who uses the power of the bots ;) [22:50:35] I was actually expecting it to use my own account to send the edits, just like https://tools.wmflabs.org/author-disambiguator/ does, but it seems not :p [22:54:24] i thought there was a userscript somewhere that let's you filter recent changes by a regex or something [22:54:56] maybe i am mixing it up with the logs filter [22:57:34] reosarevok: it should be listed on https://tools.wmflabs.org/editgroups/ [22:57:56] Awesome, thanks [22:58:07] Wait, no [22:58:09] hm [22:58:11] That shows only latest edits [22:58:16] if it's not, then I have no idea :/ [22:58:19] Oh, no [22:58:20] "See all" [22:58:27] It's just the same color as all the other links :D [22:58:31] (and look) [22:58:36] Perfect :) [22:58:59] * reosarevok tried to run this for everyone with both an Estonian Researcher DB ID and ORCID [22:59:07] Hoping it wouldn't be a huge mess [22:59:11] Seems... ok ? :) [22:59:56] you're touching ORCIDs? may god be with you :D [23:07:27] I'm not, the bot is :p [23:07:38] The ORCIDs were already there :p [23:08:05] (the good thing about Estonia is we don't have that many researchers anyway so name clashes are very rare - if someone is in orcid, 99% chance it's the right person) [23:13:21] last time i looked, the identifier was a mess. [23:15:10] I mean, a lot of these ORCID pages are basically empty [23:15:23] The few that are not are CERN people and whatnot, probably trustworthy data [23:15:26] ... I hope :p