Even after enabling threading in uwsgi.ini, the log says enabled but it isn't.
@yuvipanda you really want my code? it don't document my code, but if you're a root you can check it out on /data/project/xmlfeed/www/python/src/app.py when I run it separately using ./app.py it works great, I use a php script located at /data/project/xmlfeed/public_html/index.php to proxy it. but it's not definitely my code, I'm a pro. and I don't feel comfortable with you look at my code. but if you want go ahead a look at it.
@yuvipanda the only way you can put a code on wmf projects is to be hosted on labs, I can't host them somewhere else, beside I know sysadmins has access to my codes and I don't care. I have limited access for others. but what's point? are you going to use my codes?! I don't think that the issue here. we're talking about threads on uwsgi not anything else.
Alright, so two unrelated issues here.
- Code on labs has to be open source. It has to have a OSI compatible license (https://wikimediafoundation.org/wiki/Terms_of_Use). I just wanted to make sure yours is.
- uwsgi reports threads are enabled, and so I suspect it is enabled. I will try out a simple test app in a few days time to see if the bug is in uwsgi, and if so report it upstream / tweak config.
Sure, but your code itself can be Open Source and available with an OSI License. For example, all of Wikimedia's code is open source, and that does not mean our passwords are out in the open.
As an admin on toollabs I think it is my duty to investigate non open source applications on toollabs. I'll start an internal thread amongst other admins and figure out how to deal with this situation.
I'll also investigate the uwsgi issue when I have time.
The actual issue reported in this ticket looks valid so far as per T91156#1098922. Hence this ticket should remain open for the time being until the reason for the current behavior is clear and it has been decided whether there is something to fix in the Tool Labs setup or not, regardless of the specific use case (and code) of the task reporter.
Please do not change task status as a sign of disagreement or disappointment. Thank you for your understanding! :)
@coren I totally understand that and knew it, the only problem here is to solve the issue without trying to run my code, I don't like people giving me advice how to code, that's what always happens when people my codes are wrong, you check if there was no issue say there is no issue, not saying your code first, and you better be solving the problem instead telling me what I already know.
There are various helpful hints for good bug reporting, with Simon Tatham's "How to Report Bugs Effectively" probably the most cited one, but saying: "It doesn't work!" and then not providing any steps to reproduce the faulty behaviour is not one of them.
Usually, bug reporters are expected to provide a minimal example that shows the error. Because you didn't do that, @yuvipanda graciously offered to debug your actual application. Most people would have been thankful for that.
So please state what you did, what you expected to happen and what happened instead so that this issue can be looked into.
System admins must be able to debug anything, coren told me it's solvable by uwsgi.ini which didn't help and even I told him on the channel he ignored now I asked yuvipanda on T91155 now coren showed up. besides I told you I don't need you to solve anything I always find alternative ways when sysadmins don't do anything beside restarting servers. and you better do your job well for what you getting paid for instead of telling me how to report a bug, now close this ticket or don't update it unless you've solved it.
So I set up a small flask app to test this (P373).
The thread did get started, and run to completion. I got the output '1', which is what I should have gotten when the thread works. So uwsgi is fine, looks like a bug somewhere else in your code?
@Mjbmr: Please review https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette as well. Be nice to people whose help you are asking for.