Bug 35497 - tomcat5 stops responding to requests, leaves zombie processes, no response to TERM signal
tomcat5 stops responding to requests, leaves zombie processes, no response to...
Status: RESOLVED INVALID
Product: Tomcat 5
Classification: Unclassified
Component: Servlet & JSP API
5.0.28
PC Windows 2000
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-06-24 15:45 UTC by Kenny Pearce
Modified: 2005-07-15 06:14 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenny Pearce 2005-06-24 15:45:09 UTC
Installation details: Tomcat standalone servlet container (standard installation
from source)
jdk1.5.0_03
Red Hat Enterprise Linux 3

Additional JARs in shared/lib: Sun AppServer SAAJ implementation (saaj-api.jar,
saaj-impl.jar)
JSP standard taglib
JavaMail

Server Use Pattern: development platform for a handful of programmers working on
servlets simultaneously. Lots of undeploying and redeploying of applications as
they change and need to be tested. 

Tomcat Invocation: started via the script included in
bin/jsvc-src/native/Tomcat5.sh, slightly modified to support the "restart"
command and installed in /etc/init.d/tomcat. 

Configuration: standard (nothing changed except hostname to IP on local network,
port from 8080 to 80, etc.)

Behavior: Twice now in the period of a week Tomcat has spontaneously stopped
responding to requests (doesn't reject them, just times out). Servlet threads
running in the background also stop. This includes the Tomcat test servlets, not
just the servlets we are developing. Subsequently, the jsvc processes (there are
two; one runs as uid root, the other as uid tomcat5, not sure why) do not
respond to the TERM signal. They must be killed with the KILL signal and
restarted before any server content (including static HTML) can be accessed. I
doubt if this is of any significance, but I think it is strange that it has
happened at almost exactly the same time of day in both cases (~16:30, system
time). The behavior is sporadic and I have as yet been unable to produce it at
will, but am working on it.
Comment 1 Remy Maucherat 2005-06-24 15:51:35 UTC
The issue is that on this (broken) OS, the thread which accepts new sockets
disappears (so Tomcat becomes dead).

See the release notes (RHEL 3 is based on RH 9):

================
Tomcat on Linux:
================
GLIBC 2.2 / Linux 2.4 users should define an environment variable:
export LD_ASSUME_KERNEL=2.2.5

Redhat Linux 9.0 users should use the following setting to avoid
stability problems:
export LD_ASSUME_KERNEL=2.4.1
Comment 2 Kai-Chun Lin 2005-07-15 12:15:18 UTC
Hello, I appeared to have the exact same problem but it happened on Windows.

Server 1:
Windows 2000
5.00.2195
Service Pack 4
Single Processor (Athlon XP 2000+)
Tomcat 5.0.28
J2SDK1.4.2_03


Server 2:
Original dev/test server:
Windows 2000
5.00.2195
Service Pack 4
1/2/4 Xeon CPUs @ 2.4GHz (removing CPUs didn't help the situation)
Tomcat 5.0.28
J2SDK1.4.2_08


Server 1 listed above worked without any problems. However, when I deployed the
service on server 2, Tomcat would stop responding after the servlets are not
accessed for a period of time (around 4-5 hrs). Executing shutup.bat produced no
visible effect. Strangely, as far as I can tell, the JSP pages worked just fine. 
When I modified the web.xml file within the WEB-INF directory of my application,
the supposely dead Tomcat did a context-reload and the previously unresponding
servlets came back alive too. After some futher testings, to my amazement, I
found that could bring Tomcat back alive by simply focus on the Tomcat console
and pressed "Enter" (I assum press any other key would work too).

I would appreaciate it if anyone can shed some light on this matter, and for now
I'll test to see whether or not having a external thread calling a dummy servlet
periodicaly can remove this problem.
Comment 3 Remy Maucherat 2005-07-15 14:14:03 UTC
For this kind of problem, you need to investigate using posts on tomcat-user,
which will yield far more useful feedback.