> Bad keyword in body, bad keyword in title, bad keyword in username ---------- Bad keyword in body - Position 0-8: Puravive Bad keyword in title - Position 0-8: Puravive Bad keyword in username - Position 0-8: Puravive
@Spevacus That pattern looks like it's already caught by Bad keyword in answer and Bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
@Spevacus 'automationagencyindia.com' is not caught by a blacklist or watchlist item.
@GeneralGrievance I don't think that does prove they're related except in subject matter? It seems like Edubirdie is quite well established, even having its own Wikipedia page (albeit one teetering on the brink of deletion). It's possibly like mentioning Apple when reviewing some other phone brand
@Laurel I have another lead. In 2018, the Edubirdie TOS page said listed Boosta LTD as the ultimate owner of the website. It was later changed to I3 Technologies, and again to Radioplus Experts. As late as 2020, PapersOwl listed Boosta Inc as its owner at the bottom of their home page.
@GeneralGrievance Eh, I just performed a regular deletion on both. Tbh, I don't like that the one is encouraging ghostwriting (aka academic dishonesty) and the other one is just saying the answer is a matter of "style or personal opinion" without actually explaining what any style guide says
@SmokeDetector While this might be spam, IMO, the munged formatting, content, and the user's prior question, make it appear to be more likely to be a failed question, rather than spam. OTOH, it's probably a good idea to watch the domains in order to catch anything further, in case it actually is spam.
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Potentially bad keyword in body - Position 4-21: trafficriders.com Potentially bad keyword in title - Position 4-21: trafficriders.com Potentially bad keyword in username - Position 4-21: trafficriders.com
@Cow @tripleee That message, and ones similar to it, indicate that SD's scanning process wasn't able to start a new scan batch (i.e., a single fetch from the SE API and scan all questions and answers returned from that fetch) for longer than generally expected. It can indicate that there's one or more messages within the current batches which are taking an unusual amount of time, but might also indicate that there were multiple watch/blacklist changes within a single scan fetch (or within the number of scan threads which that SD instance can launch). It's significantly more likely to happen when the SD instance is first becoming active, as the instance won't have any posts in its recently scanned posts record, so is scanning all posts which it fetches from the SE API, rather than skipping any that were unchanged from when previously scanned.
A single such message shouldn't really be considered a problem. OTOH, if there are multiple similar messages with increasing times, then it would probably be a good idea to take a look at SD's queue (i.e., !!/queuestatus) and threads (i.e., !!/threads) to see if something hinky is going on. Rebooting might be called for, but is also not unlikely to result in the message which SD is taking a long time to scan to be started over from the beginning, and still taking a long time to scan.
Such messages are much more likely when running on my SD instance, which is generally run on a compute instance with 2 CPU cores, rather than when SD is running on Thomas Ward's SD instances which typically run on compute instances with 4 CPU cores. The number of scan threads which the SD instance is permitted to run is one scan thread per actual CPU core.
As a result of having more CPU cores available, Thomas Ward's instances are much more likely to be able to launch new scan threads, even if a single scan thread ends up taking a substantial amount of time to complete a scan, which does happen. In general, two CPUs are sufficient for SD to keep up with real-time, even under most adverse conditions, but there's dramatically less unused CPU capability with only 2 CPU cores compared to having 4 CPU cores available.
The level of CPU resources needed is, overall, a concern and something for which I'm considering various mitigations to have SD not expend so much processing capability in a few/several areas where the processing can/should be reduced or where the processing can be made redundant.
@Makyen That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
