Search failed (5) Too many users

03 Oct 23: One server was relocated, the server currently doesn't have a public IP address since in the meantime it is running on starlink. I wrote some additional tunnel code running separately to handle this. When the server is engaged the connection is 5600+ days uniform (since around 24 July 2008). In the unlikely case I disengaged the server because of some problem the retention is 1200-3800 days depending on newsgroup. If you experience any issue please let me know.

29 Nov 23: Because of encrypted and obfuscated posts flood mass posted by a few nzb indexing websites using usenet servers as private storage for their members to download the posts - the situation with the content is pretty chaotic since their purpose is to post in such a way, so users must use their website exclusively, when the website disappears - the encrypted posts just eat usenet providers' hard disk space uselessly. If you can't find something specific please let me know at alexbirj at gmail dot com what exactly you can't find for me to check how it is possible to retain the posts. Non-obfuscated posts shouldn't be affected at all, let me know if you notice anything missing.

29 Nov 23: The search protocol had to be upgraded to extend 3 byte (16M+) limit on the server side for number of sets per instance, so at least the version 5.8.3 is needed to access it, otherwise should be no any difference.
Post Reply
cthulhiac
Posts: 13
Joined: Tue Jul 24, 2007 2:59 pm

Search failed (5) Too many users

Post by cthulhiac »

Is this due to a DoS attack or is there a limit to the number of users? First time I've seen it.
alex
Posts: 4514
Joined: Thu Feb 27, 2003 5:57 pm

Re: Search failed (5) Too many users

Post by alex »

i noticed, checking it, it could be it ran out of memory after running for months, restarting it now.
alex
Posts: 4514
Joined: Thu Feb 27, 2003 5:57 pm

Re: Search failed (5) Too many users

Post by alex »

Looks like it is running ok after reboot.

Update:

It happened second time after 4 days, while I was monitoring the server with very similar picture.

Given the timing it could be because of recently exposed Windows RDP vulnerability, which I have now patched manually.

https://portal.msrc.microsoft.com/en-US ... -2019-0708

There is some "research" exploit code available, maybe enough to make the system unstable, but without yet taking full control.

The affected server uses the standard RDP port, so only it was hit.

If it won't happen again this was the cause.
Post Reply