Hi - I don't think 'webservice start` is necessarily the right command to
start up services - doesn't that just default to a php server? If you're
running python or ruby or something else you need to run whatever the
webservice startup command is you initially ran. The service.manifest file
should
I mean in Phabricator - https://phabricator.wikimedia.org/T271181
Arthur
On Mon, Jan 4, 2021 at 8:14 PM Arthur Smith wrote:
> Ok, see T271181 in Toolforge.
>
> Arthur
>
> On Mon, Jan 4, 2021 at 6:59 PM Arthur Smith
> wrote:
>
>> I've restarted it 3 times a
Ok, see T271181 in Toolforge.
Arthur
On Mon, Jan 4, 2021 at 6:59 PM Arthur Smith wrote:
> I've restarted it 3 times already!
>
> On Mon, Jan 4, 2021 at 5:41 PM Brooke Storm wrote:
>
>> Hello Arthur,
>> I suspect this could be related to a serious problem with L
en’t already, restarting the web service might not be a bad
> idea.
>
> If it doesn’t clear up with a restart, please make a Phabricator task to
> help coordinate.
>
> Brooke Storm
> Staff SRE
> Wikimedia Cloud Services
> bst...@wikimedia.org
>
>
>
> On Jan 4,
e is doing
though!
Help would be greatly appreciated, thanks!
Arthur Smith
___
Wikimedia Cloud Services mailing list
Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud
Any update on this? I still get a "The MariaDB server is running with the
--read-only option so it cannot execute this statement" message when I try
to do anything!
Arthur
On Tue, Nov 10, 2020 at 10:52 AM Brooke Storm wrote:
> This will be happening in around 10 minutes. ToolsDB will be
ne with similar docker run command(s) to install and run pip etc.
Do you think it's worth adding this to the wikitech docs?
Arthur
On Tue, Jun 2, 2020 at 2:36 PM Arthur Smith wrote:
> Depending on which web framework you’re using, there might be better
>> options than exactly r
in-browser debugger when an error
> occurs. It’s amazing, I can’t recommend it enough.
>
> Cheers, Lucas
>
> Am Di., 2. Juni 2020 um 15:28 Uhr schrieb Arthur Smith <
> arthurpsm...@gmail.com>:
>
>> I've found it very useful with php tools to use the instructions here:
&
I've found it very useful with php tools to use the instructions here:
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#PHP
where it says "You may run the container on your *local* computer (not on
Toolforge servers) by executing a command like this: ..."
which allows testing
Ah, never mind, I missed the OAuth section in the documentation! Will
request the new consumer then, thanks.
On Fri, May 15, 2020 at 3:53 PM Arthur Smith wrote:
> Hi all - I was exploring my tool (author-disambiguator) - which uses
> OAuth. Is there a recommended practice for fixing/up
Hi all - I was exploring my tool (author-disambiguator) - which uses OAuth.
Is there a recommended practice for fixing/updating the OAuth details? I
got an OAuth error when I first connected using the new URL, but that was I
think because the callback is hardcoded in the OAuth configuration to the
or it falls back on the old defaults?
Arthur
On Mon, Feb 24, 2020 at 6:56 AM Arturo Borrero Gonzalez <
aborr...@wikimedia.org> wrote:
> On 2/23/20 8:51 PM, Arthur Smith wrote:
> > Actually I am beginning to suspect the 500 server errors are caused by an
> > out-of-memory
Actually I am beginning to suspect the 500 server errors are caused by an
out-of-memory condition. Do the new kubernetes containers have lower memory
usage limits than the old ones?
Arthur
On Fri, Feb 21, 2020 at 11:14 AM Arthur Smith
wrote:
> I had been planning to switch my tools o
I had been planning to switch my tools over before it was forced, so I took
care of that last night - thanks, it seems to have gone smoothly. And I
love the new grafana dashboards!
One question - I seem to be getting some more timeout-related 500 server
errors. Was there a change in how that is
Have you tried logging in to the pod to see if you can tell anything about
what's going on? Process is described somewhat here:
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes
I.e. find what the name of your "pod" is:
1. kubectl get pods
Then log in to it:
2. kubectl exec -it --
a
better idea what's going on when something like this happens next time. If
anybody has good suggestions for how to monitor toolforge web services in
kubernetes I'd definitely be interested!
Arthur
On Tue, Dec 17, 2019 at 9:21 PM Arthur Smith wrote:
> Thanks! One response to your questions be
Thanks! One response to your questions below...
On Tue, Dec 17, 2019 at 6:18 PM Bryan Davis wrote:
> On Tue, Dec 17, 2019 at 1:50 PM Arthur Smith
> wrote:
> > [...]
>
> > I run the wikidata author-disambiguator -
> https://tools.wmflabs.org/author-disambiguator/ - and
Is this the right place to ask this?
I run the wikidata author-disambiguator -
https://tools.wmflabs.org/author-disambiguator/ - and since a few hours ago
it seems to be constantly freezing. I've restarted it 3 times today
already. It runs ok for a few minutes, but then at some point when I try
Note - restarting the web service (with 'webservice restart') does
clear up the zombie background processes, but that's not particularly
friendly...
Arthur
On Tue, Nov 12, 2019 at 1:35 PM Arthur Smith wrote:
>
> I'm running into an issue that child processes don't die when they are
>
I'm running into an issue that child processes don't die when they are
finished - this appears to be caused by lighttpd running as process 1
and not "reaping" orphaned processes. Is this a known issue that
there's a standard workaround for? The specific configuration here is
your standard
Things seem broken today - anything anybody can point to regarding the problems?
Arthur
___
Wikimedia Cloud Services mailing list
Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud
21 matches
Mail list logo
