>>162227 (you) from the Bunker

Now I see thread.js being loaded. That mimics green threads in JavaScript and is a good sign. Jim, you need to check a .gif file called something to the affect of - batch.gif, seems like a suspect file that could have embedded code inside the gif that is screwing the site up. I only saw that because it is an unusual name and could be some type of batch file or script. Seems there is also a cycle of images trying to load that fail and no coincidence that the bottom image ad does not load either. Please remove that code, it is not needed and very problematic.

>>23689257

Not really, it was a little laggy, but that is about it. But I have only been on there for the last hour or so.

Listen Anons, I do not think it was a DDOS problem and I do not think most are, I think it is an image server problem that is eating up resources and getting into a bad state. Even though proto went on and off. I have this page load from before, and from what I see, there is a cycle of two images that keep trying to load over and over again, which is probably the last image on this page for an ad, usually a picture of a dog. The image name is a long string but one starts with 622…jpg and the other one starts with 16e…jpg. It is an in an infinite loop of fails but those are requests that eat up resources to the image server. So when 8kun tries to load, it contacts the image server, but it is busy in a failed infinite loop. I have watched these pages load all the time and when the image server is not giving images, it is always because of failed images loading. Those images 622 and 16e jpegs are requesting a bad url also which is causing the failure:

This site can’t be reached

softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.

So mystery solved. Really not DDOS in the sense from outside attacks but bad image urls being requested over and over that is putting the image server, WebDav, into a locked single threaded state, eating up its resources, then when 8kun tries to speak to the image server it too becomes busy waiting for a proper response from the image server. So then it gets to the point that when we go to 8Kun the Proxy Server, NGINX, says, service is unavailable, because it detects a busy signals from the 8kun server.

Hope that makes sense.

>>23689343

Yes, I am 100% correct and here is why. I am posting this from another browser tab and when I go to inspect for failed images, I get none, zero; and the bottom image ad is loaded of a frog on a unicorn with an image name of 11b83ef4c4ff4a50a0d37f041693bd0c.jpeg. So, something is happening in the code that loads those ads at the bottom with:

https://softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve.softserve….

Which causes a response of

This site can’t be reached to 8Kun and 8Kun then tries to cycle with another ad image, which is also bad, then goes into an endless loop of two bad image ads, eating up the image server resources, which eventually locks up the 8kun server waiting for a proper response of a resource, and then NGINX sees all this busyness and reports back that the service is unavailable with a 503. That add server at the bottom for some reason is generating a bad source for the image as https://softserve.softserve….

This should end all these outages when fixed, because they are not outside denial of services but a bad URL in the source of the images being loaded into the ad server.

Any questions?

>>23689343

>>23689400

Do any anons have problems with images loading slowly from time to time? You get the page text, but the image takes time to load?

>>23689447

Images do load a little slower, but many times people here use ASCII images because they images do not load at all. So the problem is worse here, which means there is an actual problem with the image server loading images and I know for a fact that what I stated is the problem. The src property of the image being loaded into the bottom ad server is getting a bad url that is killing the image server, then the 8Kun server, and NGINX proxy server then sees it all and reports back, service is unavailable with a generic message that has nothing to do with the real problem like "we are down for maintenance" because it is just a fill in the blank message by site admins and not a real diagnosis by code reflection.

But just so you know, most people who build sites rely on other people's code to transfer images and have no knowledge of low level IO. Like I said on the bunker, most sites rely on WebDav which was mainly written with Java's file IO, a file paradigm, instead of the newer NIO or NIO2 libraries, a network multi-threaded paradigm which are ten times more complicated.

>>23689454

>Govt. shutdown affecting 8Kun?

>Fuckery afoot?

>WTF?

I just gave you the reason for these outages, and probably all of them. Here:

>>23689343

>>23689400

Images are being loaded with a bad source url "<img src="https://softserver.softserver.softserver…"/>

with either bad code reflection that gets into a bad state or someone is doing it intentionally.

>>23689466

>Even Google doesn't believe you.

You know what I said makes sense. Sorry to disappoint you guys, there is no denial of service of the cabal trying to attack our little website, it is just a bad URL in two images that keeps crashing the image server, then 8Kun, then NGINX reports back a generic message "we are down for maintenance" because it sends that response when it gets a 503 which is a lack of response from any server.

Sorry, not the FBI, the Cabal, the Elite, Aliens, nor Freddy.