[01:43:08] !log tools.stewardbots `./SULWatcher/manage.sh restart` db connection down [01:43:09] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [05:45:55] Wikipedia is very slow here in germany. 2 min 12 seconds for opening the history of an article [05:51:08] Yeah me too. Looks like they're working on it. https://www.wikimediastatus.net/ [05:52:12] Thx [11:12:23] hello :) [11:12:55] do you happen to know where the following address has been moved http://a.www.toolserver.org/tiles/osm (It's open street map) [11:19:21] I think the new domain would be https://tiles.wmflabs.org/ (or others under https://wikitech.wikimedia.org/wiki/OSM_Tileserver / https://openstack-browser.toolforge.org/project/maps), but it doesn’t seem to be running at the moment (https://a.tiles.wmflabs.org/tiles/osm) [11:54:58] marcinr: https://phabricator.wikimedia.org/T282889 it seems "Those urls should be of the form: https://[abc].toolserver.org/tiles/osm/12/2103/1346.png (with everything after /tiles being parameters)" [11:56:23] not sure though... [12:25:11] Hmm … crontab -l | egrep -v "^#|^$|-release buster " I get 4 lines with "jlocal" Is that the reason for the mail with the reminder to move to buster? [12:25:28] I think, I can ignore it [12:26:03] what are you using jlocal for? [12:50:14] Cleaning logging output once a month [12:50:45] and for a watchdog which restarts the job if it hangs/has died [14:39:00] Wurgl: these are the job names -- https://grid-deprecation.toolforge.org/u/wurgl -- If they were jlocal I would not expect them to show up in the grid jobs accounting report that feeds this dashboard. jlocal jobs run directly on the cron server without going to the grid. [14:44:09] Aha! These got started from within a php script which is running with jlocal [14:44:12] Fixed [14:44:38] excellent :) [14:47:24] marcinr: Lucas_WMDE gave the correct URLs, but that service is likely to disappear for lack of maintainer interest. A bit more information at https://phabricator.wikimedia.org/T187601#7642399 [17:28:00] !log tools deploy tools-webservice 0.83 T307693 [17:28:07] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [17:28:07] T307693: Bad Request error when starting a Kubernetes service - https://phabricator.wikimedia.org/T307693 [19:28:13] I am trying to migrate python cronjob from grid to k8s. [19:28:14] Using toolforge-python37-sssd-base:latest image. I receive: [19:28:15] [19:28:17] import mysql.connector [19:28:18] ModuleNotFoundError: No module named 'mysql' [19:28:20] [19:28:21] I tried 'pymysql' instead of 'mysql' but got the similar result. [19:28:23] [19:28:24] Which Python module is supposed to be used to connect to the Toolforge database? [19:30:02] ^ the same question came up yesterday and it turned out mysql is not available in the k8s container [19:31:25] avsolov: 17:34 <@taavi> musikanimal: the container images are kept as small as possible be design, so for now your best option is stick to the grid [19:32:03] @avsolov: nothing by default, create a virtualenv and install the package from pip [19:38:19] you may find this documentation useful: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Python#Virtual_environments [19:49:13] another thing that didn't occur to me the other day: I can use `webservice --backend=kubernetes [image] shell` to get the runtime you want and install things (even though you don't actually have a webservice running). This is how I am installed Ruby gems, sort of similar to activating a Python virtualenv [19:51:45] *installing [20:11:25] related, I need `libssl-dev` on the buster grid engine, or else my IRC bot is dead :( Not sure if the package is available on k8s, but I can't use k8s due to T306391 [20:11:26] T306391: Allow Toolforge scheduled jobs to have a maximum runtime - https://phabricator.wikimedia.org/T306391 [20:12:22] !log tools.wikibugs Updated channels.yaml to: b9b4697dfe8a316d830a85e4c283f90a86b56513 wikibugs: relay WikiSEO to RhinosF1's channel [20:12:24] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [20:12:47] !log tools.wikibugs Restart webservice so post-merge pull hook works again [20:12:48] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [20:13:27] is it really not there already? [20:13:41] wait sorry I was checking in the k8s container! [20:14:02] never mind :) But I'm at a loss as to why my IRC bot won't start. I'll keep debugging [20:14:12] * legoktm phew [20:14:15] ii libssl-dev:amd64 1.1.1n-0+deb10u1 amd64 Secure Sockets Layer toolkit - development files [20:14:16] hehe [20:14:18] (for reference) [20:16:11] that said, we should be installing libssl-dev in most language runtime containers [20:16:28] because of various language packages that need to build against openssl [20:16:34] so if you do hit that, please file a bug [20:16:46] I'm having some issue with OpenSSL, according to my web searches. I get from the eventmachine Ruby gem, "Encryption not available on this event-machine". This is on the grid, Ruby 2.5.5. The gem installed fine though... [20:18:07] to confirm, you installed the gem on a buster host, and are running the job on a buster grid? [20:19:01] let me check one more thing... [20:19:34] I would also double check what openssl version it's compatible with, because IIRC stretch had both libssl1.0 and 1.1, while buster is just 1.1 [20:23:18] * legoktm bbl [20:23:23] okay, so because of various issues I have some bot tasks running on k8s and some on the grid, so I keep getting confused where I installed things. Anyway, I double-checked I installed the gem on the grid, Ruby 2.5.5, and the path is set correctly to load gems from there. It's using the latest version of eventmachine. Still got the same error. I'll see if it requires libssl1.0 [20:23:25] mkay [22:08:08] how would I give a job more memory in a jobs framework YAML file? [22:13:18] musikanimal: add something like `mem: 1Gi` [22:14:06] thanks, I'll try that [22:16:00] Example: https://github.com/jjmc89-bot/jjmc89-bot-toolforge/blob/8c7426a2c0374ba023d41958ac15e946f1dad67a/cronjobs.yaml#L5 [22:17:02] gracias [22:18:13] I think I managed to get my IRC bot working on k8s tf-ruby27, but if it performs anything like it did on the old grid, it will eventually die. Hence why T306391 was important for my workflow, but I apparently can't use the Buster grid because of the problems I mentioned above [22:18:13] T306391: Allow Toolforge scheduled jobs to have a maximum runtime - https://phabricator.wikimedia.org/T306391 [22:18:32] so hopefully giving more RAM will keep it up [22:54:33] musikanimal: posted a suggestion on the task [22:55:29] thanks [22:57:53] JJMC89: next question, can we bump up the retry limit? [22:59:10] it isn't user configurable, but it can be adjusted in toolforge-jobs [22:59:32] (for everyone) [23:00:00] gotcha, ty [23:00:09] so then maybe the bash wrapper script catches the timeout and restarts the job [23:00:19] so the pod keeps running even though the inner process has a timeout set