[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, pattern-matching website in body, potentially bad keyword in body, +2 more: Nayvi Serum: The best Apple? by miantfrndy on apple.SE (@CalvT)
@Andy Long story short: Tewards instance lost all chat connections, then Undo's PI came online, so 2 smokedetectors were running along side. Then we realised that we could fix the chat connection with an --autopull commit, and now Undo's pi is the only one running, But this one doesn't have git credentials apparently
PSA: Smokey is a little unstable ATM. It's dying spontaneously. Until we get it fixed up, try to avoid using some of the more complex commands (blacklists, etc). Thanks for your patience
Sorry I wasn't around earlier to host. I was watching a movie and was away from the computer.
Hopefully I should have a more permanent instance of smokey up and running by the end of the weekend, so we shouldn't have as many issues as we did eariler today
@Ferrybig I'll answer that in parts. For Midnight Eclipse: It's behind a NAT device, but I don't have any flow control rules on there for it. It in and of itself is a VM on one of two ESXi hypervisors jacked directly into the switches. That said, these timeouts weren't caused by the firewall from what I can tell.
For Solar Flare: its behind an iptables rule for NAT, but that's really just a MASQUERADE rule. There's no flow control on there, it's in a container that's on a network bridged right to the ethernet port on the host system.
I'mma launch Solar Flare shortly
@Ferrybig I normally have two. I've been pissing around with Solar Flare's networking recently oops
@Ferrybig it may also be that i have an unstable cable on the network connection between the hypervisor and the network - i'll check that in a couple months when I'm back in my apartment. I think Solar Flare should be coming up shortly?
yep it's pinging to MS in standby mode.
@angussidney Note I've brought up Solar Flare again since i stopped messing with its networking for a bit.
that should definitely run more stable than Midnight
my guess is maybe a dying NIC port too on the hypervisor that Midnight is on but I can't fix that from here.
@NobodyNada wouldn't it be better if you ran it on your account (though that will be irritating if you're running it all the time) as fire's account does not have access in tavern (not enough rep)?
In the coming days we'll have a few official instances of Smokey up and running. With the holiday weekend in the US though, it may be a bit slow for some as they are traveling.
My webserver (Ubuntu box) sits running almost idle the whole time on an (probably overpowered) EC2 machine. It has to be running continuously anyway and has some insane uptime. If I'm already resigned to paying for that every month, what's stopping that instance running Smokey with the amazon guaranteed uptime and actually making use of the EC2?
@Henders Sometimes, you might get pinged when a breaking change is accidentally introduced to code base, or a breaking change is introduced in SE that requires you to pull manually
True - I'm here the whole week for defs and then usually around at the weekend (although if I got pinged I would see it on my phone and come on specially for that.. )
Smokey itself isn't heavy to run. The problem is that the services it depends on aren't the most stable. SE's websockets die frequently. The API has the occassional issue. All of that leads to problems.
@quartata maybe that's a bug? Fire uses SwiftChatSE and I hardly ever remember for it to lose the chat ws. It has been running 24/7 since a couple of months
though it does crash, but the script auto reboots it
Ok, I should have two backup instances running under my account now.
I'll be gone until Tuesday; ping me if you need anything (although I don't think I'll have SSH access, so I won't be able to do much besides asking my mom to unplug a Pi.)
