tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Al Sutton" <>
Subject RE: The FIX - Shutdown not working under SLES8 and FC2
Date Thu, 03 Feb 2005 19:34:47 GMT
Is there any reason why it doesn't try localhost first? Using localhost
before anything else would have the following benefits;

a) Would ensure that only really strange network configs would be affected
(i.e. those where localhost is not the local host).
b) Make use of the speed advantage some OS's have in their implementation of
the loopback address.
c) Avoid any wacky differences in the implementation of
InetAddress.getLocalHost() between JVMs/OSs/etc.

Off the top off my head I can't see the advantages of using the result of
InetAddress.getLocalHost() first.


-----Original Message-----
From: Bill Barker []
Sent: 03 February 2005 19:11
To: Tomcat Developers List
Subject: Re: The FIX - Shutdown not working under SLES8 and FC2

If no address is configured, ChannelSocket attempts the shutdown on
InetAddress.getLocalHost().  Personally, I'm not inclined to change this as
it points to a network configuration problem if this is unreachable.
However, you might try complaining to Sun about how they have implemented
getLocalHost on SLES8.

----- Original Message -----
From: <>
To: "Tomcat Users List" <>
Cc: <>
Sent: Thursday, February 03, 2005 2:14 AM
Subject: The FIX - Shutdown not working under SLES8 and FC2

After some playing around I think I've tracked down what the fix is, and
I'd like to throw an idea out as to what could be happening.

First the fix. The fix is to explicitly state in the AJP13 connector
that the connector should ONLY bind to the loopback address (i.e. add
address=""). Maybe this should be made the default because;

a) it's a fix to the issue.
b) it also enhances security.

Those people who are using AJP13 between machines should have the
knowlege to re-configure the connector to allow connections between
different machines.

Now the suggestion as to why this is happening.

My machine is behind a firewall, and therefore has non-routable IP
addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on
the machine the hosts file resolves it to the private IP, if you look
it up using DNS it resolves to the public IP address of the firewall.
If you lookup the machine name only (a) from on the machine or anywhere
else it resolves via DNS to the public IP of the firewall.

>From what I can tell the AJP13 connector looks up the hostname only,
(which resolves it to the public IP address), then tries to connect to
the AJP13 port on the public IP address, and because the firewall
blocks this traffic, does not connect, and then gives up.

To back this up I have put the hostname on it's own into the hosts file
(i.e. a resolves to the private IP), and everything worked again.

Before everyone shouts "you've got a strange config, it's your problem",
I'd like to re-iterate that this issue can be avoided in many ways, and
my personal beleif is that the order of preference of fixes would be;

1) Add the address="" to the default server.xml (which also has
the side effect of increasing security).
2) If no address is specified then make the shutdown system start by
trying to connect to localhost as opposed to what seems to be the
current behaviour of attempting to resolve to an external address
3) Require everyone to have the short hostname configured to resolve to
their local IP.

The reasons for this ordering is that 1 is the least effort by the
fewest people, 2 is more effort but by a small group, 3 has a potential
impact on all users and no matter where you document it will still be
missed by those who beleive in unpack and run.



Al Sutton <> wrote on 03.02.2005, 07:58:16:
> Ben,
> Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;
> [al@alsutton al]$ env | grep -i JAVA
> JRE_HOME=/usr/java/jdk1.4/jre
> bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
> JAVA_HOME=/usr/java/jdk1.4
> [al@alsutton al]$
> I've tried this on two machines, one an Athlon XP 2400+ running FC2, and
> other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so
> I'm pretty sure it's not hardware. The machines are also geographically
> seperated and do not operate on the network (ones on my LAN at home, the
> others on a LAN at work), so I'm pretty sure it's not related to the
> environment external to the machine.
> I'm going to upgrade to _07 and get the latest kernel and try again, as
> currently the only difference seems to be that your execting startup and
> shutdown from within the bin directory and I'm executing it from the top
> level (i.e. doing bin/ and bin/
> Thanks again,
> Al.
> -----Original Message-----
> From: Ben Souther []
> Sent: 02 February 2005 23:32
> To: Tomcat Users List
> Subject: RE: Shutdown not working under SLES8 and FC2
> On Wed, 2005-02-02 at 17:11, Ben Souther wrote:
> > On Wed, 2005-02-02 at 16:43, Al Sutton wrote:
> > Hmmm The latest updates gives me;
> > >
> > > Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon
> i386
> > > GNU/Linux
> > >
> > > and I'm on JDK 1.4.2_06 as opposed to _05.
> > >
> > > Would it be possible for you to upgrade?, I'd like to have the exact
> same
> > > environment, but please don't put yourself out or risk a critical
> > > environment.
> OK, here you go.
> It turns out that I did have _06 on this machine. I also have
> 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)).
> Once again, I started and stopped without a problem.
> Here is the screen dump:
> --------------------------------------------------------------------------
> ----
> [bsouther@bsouther bin]$ uname -a
> Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686
> athlon i386 GNU/Linux
> [bsouther@bsouther bin]$ export JAVA_HOME=/usr/local/j2sdk1.4.2_06
> [bsouther@bsouther bin]$ ./
> Using CATALINA_BASE:   /home/bsouther/tc_test/jakarta-tomcat-5.5.7
> Using CATALINA_HOME:   /home/bsouther/tc_test/jakarta-tomcat-5.5.7
> Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp
> Using JRE_HOME:       /usr/local/j2sdk1.4.2_06
> [bsouther@bsouther bin]$ ./
> Using CATALINA_BASE:   /home/bsouther/tc_test/jakarta-tomcat-5.5.7
> Using CATALINA_HOME:   /home/bsouther/tc_test/jakarta-tomcat-5.5.7
> Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp
> Using JRE_HOME:       /usr/local/j2sdk1.4.2_06
> Created MBeanServer with ID: e94e92:101d55eb6c4:-8000:bsouther:1
> [bsouther@bsouther bin]$ ps -ef | grep java
> bsouther  4714  4595  0 18:19 pts/0    00:00:00 grep java
> [bsouther@bsouther bin]$
> --------------------------------------------------------------------------
> ----
> This matches your configuration exactly.
> I also tried with _07 and the latest kernel (as of this afternoon
> ***.12 I believe).
> And you definitely aren't running with any JAVA_OPT settings?
> Maybe you have a hardware issue.
> Have you tried on another machine?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

This message is intended only for the use of the person(s) listed above as
the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)

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

View raw message