0

I'm having an issue with the default configuration of tomcat 7 on Debian 8.

Problem: I got the cpu of my server, due to java process, jump to 100% and stay there for hours making the server slow. If I restart tomcat server the cpu goes again to 1%. After some hours the problem starts again.

Java Application status: No custom java applications are installed on tomcat so this is probably a tomcat issue.

Logs: Watching catalina.out I found this error message in corrispondence to the cpu pitch start

Jan 19, 2017 1:03:23 AM org.apache.coyote.http11.AbstractHttp11Processor process INFO: Error parsing HTTP request header

How to replicate: After the server restart I have tried to access the tomcat server home page using https by visiting this url through a web browser

https://domain.com:8080

and voila, the cpu start to go crazy and I get the log as before.

What does it means: This means everyone with a special request can DDOS my server

Question: Is there any way to solve this issue possibily without changing my linux distribution or packaged versions of tomcat used by apt?

I'm using a fresh debian 8 default image from Google Compute Engine. tomcat 7.0.56 Java 1.7.0_111

  • An update: I sent a bug report to Debian team, details are here bugs.debian.org/cgi-bin/bugreport.cgi?bug=854551 . The issue is solved on Tomcat version 7.0.56-3+deb8u8 for Debian 8 and version 7.0.28-4+deb7u10 for Debian 7. An apt-get upgrade now solve this issue. – Marco Brenna Feb 15 '17 at 11:33
1

I had exactly the same problem with Debian 8, tomca7.0.56.

For me uprading to the backport version solved it. I upgraded tomcat7, tomcat7-common, libtomcat7-java and libservlet3.0-java to version =7.0.73-1~bpo8+1 (like this way: apt-get install tomcat7=7.0.73-1~bpo8+1)

I think we have a massive security issue with the current release of tomcat 7.0.56 in Debian 8. With the standard configuration everyone who simply calls https:// domain.tld:8080 causes thes cpu scaling to 100% until you restart the tomcat!

  • 1
    Upgrading to the backport version solved the issue to me too and I think this is a massive security issue too. Upgrading to backports is a real solution but it's better to avoid backports in a production enviroment. It could be great if this can be solved on stable. I look for informations about how to report this to Debian team. – Marco Brenna Feb 3 '17 at 8:54
1

In short, apply scientific method.

  • Find out what is listening on port 8080.
  • Find out how it is configured.
  • Understand what it is doing.
  • Take appropriate action
  • 1
    As I said, on port 8080 is listening tomcat, is a default installation with default configuration, is doing it's work but in a wrong way, the log are not so informative, this is why I ask. I always apply scientific method as a technician and I tried to be as informative as I could in my question. I thought my question might help other people to solve my same problem and raise a problem detected on a default installation. I ask here for find help from experts and be helpful. Maybe my question is not complete. I will solve my problem on my own. Thanks – Marco Brenna Jan 24 '17 at 9:04
  • There is no evidence of your having carried out any diagnostics in your question. – Iain Jan 26 '17 at 8:12
1

I have exactly the same problem, and the same system configurations. When I reboot the server, it will be OK for a day or two, then again tomcat7 uses about 99% of the cpu.

This time I did this:

service tomcat7 stop

And it is still working for me. I don't use Java, as you mentioned, so its OK for me.

  • I restart tomcat7 server too but after 2 days the problem happened again, and again, cpu 100%. On my server the problem occours not randomly, it happens because there is some sort of bot that try to bruteforce the password of tomcat manager on my ip every day; when it tries to access tomcat manager using https at the address domain.com:8080/manager the 100% cpu begins again... – Marco Brenna Jan 26 '17 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.