tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl" <>
Subject Re: Tomcat dies suddenly
Date Sun, 07 Feb 2010 12:02:48 GMT

Thanks for your information.

I am not certain where the glibc versions I previously gave came from 
because... as you noted, they are not correct.  The correct glibc version is 
2.9 and the threading version (I hope I am stating this correctly) is NPTL 

The kernel version is  From the Slackware 13.0 release notes, 
'We've used the well-tested and recently patched kernel'.  I 
assumed that was about as good a kernel as I could get... was I wrong?

I will try LD_ASSUME_KERNEL=2.4.1 (the Slackware site seems to indicate my 
version supports this setting) on one of the servers (so I can quickly 
revert to the other one if the setting doesn't work.)

I will add the 'XX:ParallelGCThreads=1 option to one of the servers and see 
how that works.

I am moving a litlle slowly because I don't want to make a nbad situation 
worse and want to be certain I can account for any improvements or screwups.

Thanks for your insights.


----- Original Message ----- 
From: "Mark Eggers" <>
To: "Tomcat Users List" <>
Sent: Saturday, February 06, 2010 9:46 PM
Subject: Re: Tomcat dies suddenly

--- On Fri, 2/5/10, Carl <> wrote:


> 1. The application runs fine on an older system. Do we have
> the glibc and kernel versions for all systems?
> The old system: P4. 1GB memory, 1.3GB swap.
> Uses swap on a regular basis. kernel is 2.4.25.
> Java is 1.5.0_01-b08. Tomcat is 5.5.23. Glibc is
> version 2.3..1.
> New systems: Server A (Dell T110) is a Xeon 3440, sever B
> (Dell T105) is an AMD. A has 4GB memory and 19GB swap
> which is never used. B has 6GB memory and 10GB swap
> which is never used. A and B both use kernel version
>, Java 1.6.0_18-b07 and Tomcat 6.0.24.. Glibc
> version is 4.3.3 for both A and B.

A couple of observations here:

Both the old new kernels end in odd numbers. From memory, I thought the odd 
kernel numbers were experimental, while the even numbers were production or 
mainline. I don't remember when this numbering system took place, but 
certainly by the time the 2.6 kernels were released.

>From, I didn't see a 2.6.29 release marked as stable.

The thread implementation has changed between the 2.4 and 2.6 kernels. You 
can see the thread implementation change by running:


I'd be interested in knowing the result of that and


on both systems, since I don't recognize 4.3.3 as a glibc version (latest 
stable is 2.11.1, so I'm assuming

glibc has some thread bugs that were fixed, but not until 2.8 or 2.9. There 
was also a persistent bug for 32-bit systems that bites Java applications 
(not your concern since you're running 64-bit) that wasn't fixed until 

So in short, I'm guessing this may be a glibc NPTL issue.

There are some observations that don't match, in that you're using Java 6 
(most problems are reported with Java 1.4 and Java 5), and that you've used 
OpenSuSE (kernel, glibc version?) with the same Tomcat failure.


For some of the earlier 2.6 kernels, you could get around NPTL problems by 
setting this environment variable:

export LD_ASSUME_KERNEL=2.4.1

which forces the use of the old linuxthreads model. I don't know if that 
option is available with the 2.6 kernel that you are using.

Another work-around has been posted on the Java bugs forum, albeit for a 
different threading problem and Java 5:


sets GC to single threads. It's not fixed in the Java bugs database, because 
later versions of RedHat Linux don't exhibit the SIGSEGV problem.

Some people report that single-threading GC solves their problems, while 
other people report that it doesn't.

Some things to try I guess:

1. export LD_ASSUME_KERNEL=2.4.1 (maybe in if your kernel 
supports this..

2. set -XX:ParallelGCThreads=1 in (JAVA_OPTS). This is an 
experimental switch, not documented here:, but 
documented here:

3. Move to an even-numbered kernel with a glibc of 2.10.1 or better. 2.10 
might be OK for your environment since the bug fixed in 2.10.1 causes 
problems for 32-bit systems only.

just my two cents . . . .


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message