User:Davidwr reports on the VP:T thread that this diff hits the limit, and I can reproduce that myself:

+1 to implementing this functionality.

Oh, my bad. I thought that was something developed by MWF.

I'm not getting how this is supposed to work. I've reconfigured my django app to log to stderr. That output is ending up in $HOME/uwsgi.log. When I run "kubectl logs", all I get is the error message mentioned above, and no additional output, no matter how long I wait.

Ah, thanks for the explanation. I just assumed it was kubectl failing to start up properly.

As I pointed out above (and opened T256482 for), kubectl logs doesn't run.

Any update on this? Any kind of workaround to get real-time logging?

Yup, I can confirm that "watch tail" is significantly faster than "tail -f".

No joy.

Yeah, my immediate goal is just to get logging feedback during development. I've never used kubectl logs, but sounds straightforward. I'll give it a try. Thanks.

Thanks to everybody for diving in and working on this. In the meantime, is there some workaround I could use? Is there some other host I could log into which has better NFS connectivity?

@Bstorm , I'm not sure if your question was addressed to me, but I don't have root on the bastions :-)

OK, I've finally found a solution. You can configure tmux to map C-p to the up-arrow escape sequence, which works around docker eating the C-p. It's hacky and duct-tapey, but it works. Still, fie on docker for not providing a way to configure/disable this behavior.

As an external observer, I'm fearful of "log everyone out". This will cause a spike in traffic to the authentication infrastructure as everybody logs back in again. Which, of course, was the root cause of this problem to begin with. Is there some way to do a rolling logout, killing say, 1% of the sessions per hour?

Oddly enough, I was able to edit logged out in an incognito window.

This is happening on enwiki as well. I'm also unable to logout! I tried Special:Logout, but it doesn't seem to do anything.

I originally got here when I opened {T230700: Special:RandomInCategory does not return all pages with equal probability} a while ago. I notice that my original example from T230700 was working through AfC work queues, and so is the example given by Ahecht, above. Makes me think that the AfC use case may be different from most other things happening on the wiki. I'm wondering if this could be solved by occasionally re-populating page_random? I could see a couple of possible variations on this.

Oh, I think I see what's going on. The previous entry is https://www.wikidata.org/wiki/Q12754671. So this is just a case of the web front end not displaying a useful error message.

Another user is apparently experiencing the same thing (and managed to capture a video of it happening). See Village Pump thread here.

To be honest, I don't remember the details around the 404. I only got it that one time, and haven't seen it since. If it happens again, I'll try to grab more data.

In T250620#6069598, @Aklapper wrote:

Looks similar to T246143

+1 to having bot edits show up in history listings. On enwiki, we have automated processes which find drafts that haven't been touched by a human in 6 months. Being able to see which edits were by bots and which were by humans supports this.

On enwiki it just fixes double redirects, so it should be fine there and I suggest unblocking

Oh, I blocked it on enwiki. I didn't realize that was the wrong place. Should I just unblock it there?

Just for the record, as the admin who performed the block, I have no objection to any other admin unblocking, once there's agreement that it's appropriate to do so.

There's a report here that duplicate inter-language links are being generated in wikidata.

I've blocked EmausBot to limit the damage.

Hmmm, based on a thread at Wikipedia talk:Village pump (technical), looks like this is widespread.

It turns out the OP is having problems accessing phab, but they implemented something very similar and that did indeed resolve the issue.

Interesting thought, thanks. I'll suggest it to the OP.

At what level is the transformation done? If the large page were broken up into sufficiently small subpages which were then transcluded into a composite top-level page, would that solve the problem?

The real problem is that in-band signalling is evil. You would think we would have learned our lesson 50 or 60 years ago.

As a mostly outsider who's been watching this, let me toss out a couple of random thoughts.

Interesting, I never even thought to try that. I just assumed I had to use the Cite tool. Thanks!

I'm fine with an internal search tool instead of external search engines, but the mailing list really does need to be indexed in some way. Not that the spammers and harvesters respect robots.txt anyway.

Another report:

OK, thanks. If it's not an easy install, it's not that important. I've found a different way to do what I needed to do anyway.

A few thoughts on this...

Ah, got it. Works fine now, and python 3.7.3 is indeed there. Thanks!

I'm not 100% sure what question you're asking. I login as user "roysmith", and then run "become roysmith-test". I guess the later is what you're looking for?

Hmmm. I've only been running in the grid environment, but it sounds like I should be looking at moving over the k8s in general. I'm reading up on that.

Can it be made available from the command line on the bastion hosts? And in the grid environment?

In T230961#5723496, @Phamhi wrote:

Python 3.7 support has been added.

If I'm reading the roadmap correctly, the fix is due to roll out for enwiki as part of 1.35.0-wmf.10, on December 12th.

Not really much I can add. RBP is the only subscription I have that's been converted to the new system, and that's one I use very rarely.

OK, it's working now, thanks.

How up to date are the replicas? When investigating abuse, you need the full history, including what has happened recently. If you need to use one tool to see the current data and another to see the historical record, that unworkable.

I just accepted the TOS (ticked the "I agree with the terms of use" checkbox, then clicked the "I accept" button). Then clicked on "Your collection", "Proxy/bundle access", then "Access resource". Still getting the same error message.

I can see my Rock's Back Pages subscription under Proxy/bundle access, with an expiration date of Dec 9, 2019. But, when I click on "Access resource", I get "We are sorry, but your account does not have access to this resource. If you think you have reached this screen in error or have questions about the resource you were trying to reach, please contact your library", at URL https://wikipedialibrary.idm.oclc.org/login?url=http://www.rocksbackpages.com

If it said, "Public logs", and I didn't see any thanks, the obvious assumption would be that thanks were not public.

My comment about the automated tools was an afterthought. My main point was that as a human exploring user and article histories, being limited to 500 per page is a real problem.

I often want to search through more than 500 items at a time. I just click on the "next 500" that's available in the U/I, then add an extra 0 to the URL. Not being able to do that is a problem.

Take a look at my sandbox history: https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&action=history. In that run of 10 edits on 15 September, it happened twice.

I don't think it's edit conflict related. I've seen this several times when there was no edit conflict. For example, the one I cited above that happened on User:RoySmith/sandbox. For sure, there was no edit conflict on my sandbox.

Just another instance of the same thing seen by kaldari, above:

Forgive me for what may be a naive question, since I'm not familiar with the codebase, but regarding:

Let me suggest a possible algorithm: