Thread: Processes in uninterruptible sleep

Originally Posted by brewbuck

That's what "make oldconfig" is for. It re-parses your older .config file and (hopefully) sanitizes it enough so that make xconfig can deal with it.

Well I learned something useful today.

Originally Posted by Elkvis

I am definitely moving in that direction, but the system has been in place for 2 years in this configuration, and this only started happening within the last few months.

Well, take this with a lot of salt: unfortunately the entire thread got lost in the last cboard DB crash, but recently Yarin posted a bunch of IP's that he'd collected using "denyhosts" in only a few weeks. These were IP's that more than 100 times tried and failed to log into the ssh port on his new VPS (which is to say, somewhere that is presumably of no interest to anyone).

It was a pretty good list and when I traced some of the IP's, they'd all been acquired thru one of two services (one in Australia and one in Holland). I don't actually think they are malevolent, but let's entertain the idea that they might be and that these people are just port scanning at random as much as possible looking for different opportunities (such as a lucky ssh hit).

Now, one of the big goals of such a person would be a successful DoS attack, which can be done with SYN flooding. Another big goal would be to not get caught. So (here's where you can reach for the salt, because it's all just conjecture) if I had a small zombie net or whatever and was trying to test it out, I might just go around somewhat randomly looking to see if my SYN requests on port 80 weren't receiving ACKs or any kind of response at all -- this might indicate the server has successfully been overwhelmed.

And if you set up a non-http server on port 80, that's what it might appear to be from that perspective (a stressed out server that DoS's easily). So if this just started happening, maybe your IP is now on someone's "experiment here" list.

Kind of far fetched. Some missing links in it. Anyway, get on the mailing list for the firewall and ask about your problem. You should NOT be just ignoring that.

Pretty much what MK said; but if you are providing a non-HTTP service on a standard HTTP port you are *asking* for problems that you could easily side-step by moving it to another, non-standard port. I am not saying this is the cause of your current problems, just that it will likely to cause you problems down the road. Standards are standards for a reason. It would be like providing a non-email service on your SMTP port; you can do it but you will get Sam and Joe Spammer slamming your server trying to find a way to make it a relay (spoofing)...

Making the symptom go away is not the same thing as diagnosing the problem. You could move to a different port, but how do you know some fault is not still lurking? I think you should try to figure out what's happening -- using the sysrq control key combo to figure out where in the kernel the thing is hanging seems like an obvious first step.