RE: The FIX - Shutdown not working under SLES8 and FC2
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. Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org 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=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and 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=127.0.0.1 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 first. 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. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the 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/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] 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
RE: The FIX - Shutdown not working under SLES8 and FC2
Costin, The answer to your question is all of the above (i.e. start with localhost, then 127.0.0.1, then try the IPv6 localhost). I'm not saying it's the only behaviour, just that trying it first may make more stable than trying a hostname first. It's als less work by fewer people to change Tomcat than to check, test, and modify (if neccessary) all the JVMs in existance. Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 04 February 2005 02:28 To: tomcat-dev@jakarta.apache.org Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 Al Sutton wrote: 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. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org 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=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and 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=127.0.0.1 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 first. 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. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the crappy comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
So let me get this right, just because you can't reproduce it on your system you're not willing to leave it open for others to check, despite the fact you haven't, as yet, told me if your using the same JDK, Linux environment, and you've not waiting for others to comment. Guess the easiest way to get round this is to move to Jetty. Al. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 01 February 2005 22:21 To: tomcat-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 9] - Shutdown script down not work DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 23:21 --- As I said originally, use the mailing list for discussion and to get suggestions from other users. This is not a discussion forum, especially not once two people (myself being the second) have confirmed that this issue is not reproducible. Please don't reopen this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0 top level build.xml
Please find attached a patch for build.xml properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which ensures that the correct versions of supporting projects are checked out when the checkout target is executed. This patch has been made against code check on in the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0 default build properties
Please find attached a patch for the default build properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which corrects the URL to obtain struts from. This patch has been made against code check on in the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0
Please find attached a patch for default build properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which alters the location of the servlet-api to reflect where the jakarta-servletapi-5 project is placed when the update or checkou targets are used to obtain the source. This patch has been made against code checked out on the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
