[12:00:13] Lucas_WMDE: have a moment to talk about wd-shex-infer ? [12:01:52] re: T300501 [12:01:52] T300501: Toolforge grid: uwsgi in buster fails to load python3 venvs - https://phabricator.wikimedia.org/T300501 [12:02:13] mmm but it uses uwsgi-plain rather than uwsgi-python [12:02:15] Lucas_WMDE: nevermind [12:34:05] how to know if and it is the normal bastion or maybe a Buster one? [12:34:43] Aniket: you could `cat /etc/os-release` [12:34:45] 54 [12:38:39] Arturo, it showing no such file [12:39:16] Anika: what about `uname -n`? [12:40:00] Aniket* [12:40:32] Arturo: ir is showing tools-sgebastion-07 [12:41:17] verify your first command, it works for me: [12:41:23] https://www.irccloud.com/pastebin/HSmHGedB/ [12:41:43] also after "becoming" a tool: [12:41:46] https://www.irccloud.com/pastebin/ioUS1RNy/ [12:43:07] yes it's working i did not entered space [12:43:13] in general we have 2 set of bastions [12:43:20] * login.toolforge.org (stretch) [12:43:20] * dev.toolforge.org (stretch) [12:43:20] * login-buster.toolforge.org (buster) [12:43:20] * dev-buster.toolforge.org (buster) [12:44:10] VERSION="9 (stretch)" it means i'm using bastion [12:44:16] ?? [12:44:45] it means you are using a debian stretch bastion, in this case `login.toolforge.org` [12:45:03] yes [12:46:05] I'm again asking my question, i'm sorry i did not able to follow up —- [12:46:06] Hi, its a very strange situation [12:46:07] when I'm running python script using jstart, getting: [12:46:09] "_pywrap_tensorflow_internal.so: failed to map segment from shared object" [12:46:10] but when I'm running same code on python3 interactive shell in tool account toolforge it running successfully [12:47:29] Aniket interactive shell means `webservice shell`? [12:48:22] Arturo its python3 shell [12:48:37] oh ok [12:49:32] Aniket: how did you create/use the python venv for your tool? [12:54:19] 1. After using become [12:54:19] 2. I’ve created venv in the main directory [12:54:21] 3. Now, If I run jstart $HOME/venv/bin/python3. $HOME/www/python/src/script.py producting error(above mentioned) [12:54:22] 4. While, [12:54:24] ... a) source ./venv/bin/activate [12:54:25] ... b) python3 [12:54:27] .... c) now same code working fine [12:55:51] Aniket could you please send an email to cloud@l.w.o or open a phabricator ticket? [12:58:56] ok Arturo [12:59:05] thanks [12:59:14] arturo: tbh I don’t remember why I used uwsgi-plain instead of uwsgi-python [12:59:22] I think uwsgi-python might have been Python 2 instead of 3? [12:59:42] Lucas_WMDE: yes, that's what I suspect [12:59:50] T300501 [12:59:50] T300501: Toolforge grid: uwsgi in buster fails to load python3 venvs - https://phabricator.wikimedia.org/T300501 [12:59:52] yup, that would seem to match https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Python#Starting_a_Python_web_service [13:02:00] so if you’re adding a uwsgi-python3 type I could probably switch to that :) [13:02:15] can we just kill python 2 support instead? [13:02:45] taavi: I just found at least 5 tools running py2 webservices today [13:02:48] (in the grid) [13:03:18] Lucas_WMDE: what about k8s? isn't that easier nowadays? [13:03:36] well, the tool submits grid jobs, so it has to run on the grid itself [13:03:46] oh right [13:04:02] * arturo makes a mental note: webservices that schedule jobs is a thing [13:04:07] and IIRC the conclusion in the toolforge-jobs task was that submitting toolforge jobs from webservices isn’t intended [13:04:21] so I didn’t spend more time looking into that [13:04:40] fair :/ although I'd probably guess that the remaining python 2 tools won't magically convert to python 3 until we force them to [13:05:13] Lucas_WMDE: will work again on toolforge-jobs once I finish the stretch->buster migration [13:05:22] will review the situation again [13:05:26] ok [13:08:16] taavi: you are probably right [22:02:28] Hi