[07:29:36] Reedy: thanks again for your help. this works now : ) [08:26:38] !log tools.wikibugs Updated channels.yaml to: 8f91a8c4f315dbe38827c0002933589837574d89 releng: Remove tags RelEng team doesn't own [08:26:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [09:02:09] Hi, I'm getting "502 Bad Gateway" with nginx when sending large chunks of text in a Flask form to my toolforge webservice. Smaller chunks work fine. UWSGI.log says "OSError: write error". Is there some config option to fix this? I'm using the standard python 3.7 kubernetes backend. Thanks. [09:20:07] Somnifuguist: yes, you can configure it in ~/uwsgi.ini, see e.g. https://phabricator.wikimedia.org/R2469:fcb85ef502036982a3f8c554f18df6c8924c2ffa [09:46:44] Lucas_WMDE Thanks! Do I have to change the "webservice --backend=kubernetes python3.7 start" command to include the "uwsgi.ini" config file? I've copied the example file you linked to ~/ but no luck so far. [10:07:55] IIRC just placing that file in the tool home directory should be enough [10:07:59] (and then restart the webservice) [10:09:53] the correct path is ~/www/python/uwsgi.ini [10:10:44] oh, is it? [10:10:54] duh, it even says that in the commit I linked 🤦 [10:10:57] sorry [10:11:20] I just remembered that I had to link it somewhere else out of ~/www/python/src/ (which is the git repo root) [10:11:32] Somnifuguist: what majavah said [10:11:47] i wonder why it is not in ~/www/python/src [10:12:26] maybe it should be, now that `webservice` has also started to look for the service.template there [10:29:12] Thanks to both. I think I'm now running into the overarching nginx header size limit. Not sure how a user can send a largish chunk of wikitext to a server for processing otherwise, though. [10:31:00] how large chunk is that? [10:37:22] about 12k bytes. Just a small script to reorder tables. [10:40:19] huh, that's nowhere near the body size limits on the toolforge proxies [10:41:53] which tool? [10:44:05] Probably an error on my side then :) https://wiki-tennis.toolforge.org/misc/ [10:48:18] I tried various "buffer-size"s (50k, 200k, 1m), but no luck. The input field requires a wikitext table to be pasted into it. [10:50:43] uwsgi buffer-size doesn’t include the request body (https://uwsgi-docs.readthedocs.io/en/latest/Options.html#buffer-size), so that shouldn’t be the issue [10:51:30] apparently there’s also limit-post https://uwsgi-docs.readthedocs.io/en/latest/Options.html#limit-post [10:51:42] (from https://stackoverflow.com/a/25932856/1420237) [10:58:55] this is what I see on the kubernetes ingress proxy (that directly then connects to the webservice): "[error] 7009#7009: *70482946 upstream sent too big header while reading response header from upstream" [11:00:31] so it's trying to send large headers, not a large body? any clues what headers that might be? [11:04:43] * Lucas_WMDE imagines a request with such a large body that the decimal representation in the Content-Length header overflows [11:06:44] Not sure. The request is "https://wiki-tennis.toolforge.org/outputmisc/?script=reverse&input=[wikitext chunk] " Is that what you're referring to? I'm afraid I'm quite new to the web side of things. [11:07:20] oh, it’s a GET request? [11:07:47] hm, the form on https://wiki-tennis.toolforge.org/misc/ has method=post… [11:12:32] It should be post the data in the fields, then get the "output" page where the processed text can be copied. [11:13:20] i think it's failing because the URL it creates to the output page is too long [11:15:21] unless there is a good reason not to, i would just remove the separate output page and just return the result on form submission instead of redirecting to separate page for that [11:15:45] +1 [11:20:10] That makes sense. I blindly followed the template for handling the requests used by the creator of the other scripts in that tool (who's also inexperienced) due to my own ignorance re the web side of things. Evidently that's not the way to do things. I'll do some learning now. Thanks for both of your help. [12:17:52] Now working as intended. Thanks again. [12:51:08] oh hihi majavah o/ just replied to you on phab [15:39:14] !log toolsbeta deploy toolforge-jobs-framework-api git version d85d93ee1c5d4be6a526cf83e806b2679dde3875 [15:39:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Toolsbeta/SAL [15:55:46] !log tools added toolforge-jobs-framework-cli_2_all.deb to buster-{tools,toolsbeta} (T285944) [15:55:52] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [15:55:52] T285944: Toolforge: beta phase for the new jobs framework - https://phabricator.wikimedia.org/T285944 [16:12:12] !log tools deploy toolforge-jobs-framework-api git version d85d93ee1c5d4be6a526cf83e806b2679dde3875 (T285944, T286107, T285979, T286485, T286107) [16:12:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [16:12:21] T286107: toolforge-jobs: Allow specifying arguments to commands - https://phabricator.wikimedia.org/T286107 [16:12:21] T285944: Toolforge: beta phase for the new jobs framework - https://phabricator.wikimedia.org/T285944 [16:12:21] T285979: toolforge-jobs with --wait hangs indefinitely if the job fails - https://phabricator.wikimedia.org/T285979 [16:12:22] T286485: toolforge-jobs: figure out logging - https://phabricator.wikimedia.org/T286485 [17:35:40] for some reason I can’t run `kubectl` in the notwikilambda tool anymore – apparently it “failed to create new OS thread (have 41 already; errno=11)” [17:35:50] (on sgebastion-07 – I’ll try dev-buster now…) [17:36:07] I don’t think I have any other processes running on the bastion under the tool account, apart from the shell [17:37:21] ok dev-buster (aka sgebastion-11) seems to work better [17:37:48] Ahh the threads limit [17:38:22] The tool account AND your personal account and any other tool accounts you are running from there matter [17:38:31] huh, ok [17:38:32] cgroups know you are sudoed [17:38:41] So that could be it [17:38:43] then I need to double-check [17:38:51] but I don’t think I’m running that much bastion stuff from other accounts either… [17:39:08] kubectl made us raise those limits before [17:39:18] It does a lot of threading [17:39:37] golang 🤷🏻‍♀️ [17:39:42] yeah, I noticed bash said it’s 250 now [17:39:47] I remember it being something like 14 [17:40:05] We may just have to increase it to account for kubectl upgrades [17:40:12] at least that got me into the habit of using `exec become` instead of just `become` ^^ [17:40:18] goroutines count against thread limits it seems [17:40:28] cgroups don't buy the hype [17:40:41] :) [17:41:22] If you make a ticket, I can try to revisit that today. I'm leaving early today, so I cannot guarantee, but this seems important. [17:41:33] I’ll create one later [17:41:36] thank you! [17:41:47] (looking into T286724 right now thanks to majavah ^^) [17:53:28] !log tools.notwikilambda only mount ~/www/python into pygments-server pod (T286724) [17:53:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.notwikilambda/SAL [18:24:14] !log tools.notwikilambda don’t mount service tokens into pods (T286724) [18:24:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.notwikilambda/SAL [18:49:56] !log tools.notwikilambda block external traffic to internal pods (T286724) [18:49:59] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.notwikilambda/SAL [20:09:15] !log admin-monitoring remove stale/errored fullstack tests [20:09:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin-monitoring/SAL [21:05:40] !log tools.notwikilambda updated pygments-server to 2d4ab81a68 (prevent open(); T286724) [21:05:44] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.notwikilambda/SAL