We do a lot of mostly-invisible stuff, and when we do something big and visible it's often like this meta post where we deal with a bunch of criticism too. Figured it'd be worth a reminder that y'all are awesome useful people doing awesome useful work :)
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Title - Position 1-29: [email protected] Body - Position 1-29: [email protected] Username - Position 1-29: [email protected]
@thesecretmaster > There have been 656 attempts to cast flags automatically on Stack Overflow in the last 3 months. We were able to cast automatic flags 653 times (99.54%) and we were unable to cast automatic flags 3 times (0.46%). The flags were 622 (95.25%) true positives (TPs) and 22 (3.37%) false positives (FPs).
And There have been 1 688 attempts to cast flags automatically on Super User in the last 3 months. We were able to cast automatic flags 1 682 times (99.64%) and we were unable to cast automatic flags 6 times (0.36%). The flags were 1 681 (99.94%) true positives (TPs) and 3 (0.18%) false positives (FPs).
Not 100% sure but think the unable to cast might refer to individual flags - so an individual post that should have been flagged might have 3 unable to flags per post.
[ SmokeDetector | MS ] URL-only title, bad NS for domain in body, bad NS for domain in title, blacklisted website in body, blacklisted website in title, +4 more: healthpurelives.com/nitridex/ by gtukrkwmx on askubuntu.com
@Magisch The problem is that your stats are network wide. On Chemistry, the stats are far far worse. That's one of the problems of looking at this as a network-wide issue: you loose granularity.
@JAD it's not very far away from the new autoflagging threshold as far as I understand. And it's not a reasonable false positive, this indicates a fundamental issue with these particular rules and how they're applied on certain sites
I wouldn't even argue statistics here. Rules based on chemical or biological terms simply should never run on sites where those topics are on-topic. They're just harmful there
@MadScientist to add to the other nopes, you can see it in the example you linked: metasmoke.erwaysoftware.com/post/62958 194 = 97 + 97 (one per rule, even if the second one got triggered twice)
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Title - Position 1-18: dentoaviation.com Body - Position 1-18: dentoaviation.com Username - Position 1-18: dentoaviation.com
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, pattern-matching website in body, repeated URL at end of long post: Andras Fiber Reviews by robertmazon on astronomy.SE
@MadScientist That's what I was thinking. I found the cron log - no error messages, and modifying the job to print s3cmd's config shows that it's identical to that of the CLI environment.
@Undo That's running it with sh (dash on Ubuntu), not bash. Should not be relevant here, I don't see any bashishms, but might be an issue at other times.
I always add export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/bin/did-you-really-scan-for-every-path-in-this-chat/bin" on top of my cron scripts, just to avoid PATH issues with my cron jobs
@Undo Obviously, the real fix would be to make sure nothing's writing to /var/railsapps/redunda/shared/log/production.log, but if that's not an option, try cat "$filename" | gzip -c | ...
@Undo Usually, logrotate handles these issues by first moving the log files to a new place, then reloading the program, and on the next rotation, apply gzip, as no problem should write to a log file for 24 hour non-stop