Re: Can't stop tomcat - connection refused
I have been using this config on a few VPS vendors for more than 10 years without anything like this. I tried the exact same setup on AWS today and it worked right away. I feel pretty sure that the VPS vendor I am trying has some sort of problem. I am working with them to solve it. Thanks! Blake On Tue, Feb 15, 2022 at 5:21 PM Neil Aggarwal wrote: > Looks like tomcat is dying or getting killed. > That is strange. I am running tomcat on a VPS with no problems. > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Can't stop tomcat - connection refused
Blake, On 2/15/22 16:58, Blake McBride wrote: # netstat -plunet Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN 10119387 632/systemd-resolve tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 22776 798/sshd: /usr/sbin tcp0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 11223212 847/postgres tcp6 0 0 :::22 :::*LISTEN 0 22787 798/sshd: /usr/sbin tcp6 0 0 ::1:5432:::*LISTEN 11223211 847/postgres udp0 0 127.0.0.53:53 0.0.0.0:* 10119386 632/systemd-resolve On Tue, Feb 15, 2022 at 3:49 PM Blake McBride wrote: Thanks, Neil, I started up tomcat and ran: curl http://localhost:8080 It returned the page. Great. I then ran: ./shutdown.sh It stopped just fine. I checked with ps. I then did ./startup.sh again. This time the curl command just hung and ./shutdown.sh gave me "Connection refused" error. catalina.out shows no errors. Linux oom killler? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Can't stop tomcat - connection refused
Looks like tomcat is dying or getting killed. That is strange. I am running tomcat on a VPS with no problems. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't stop tomcat - connection refused
# netstat -plunet Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp0 0 127.0.0.53:53 0.0.0.0:* LISTEN 10119387 632/systemd-resolve tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 22776 798/sshd: /usr/sbin tcp0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 11223212 847/postgres tcp6 0 0 :::22 :::*LISTEN 0 22787 798/sshd: /usr/sbin tcp6 0 0 ::1:5432:::*LISTEN 11223211 847/postgres udp0 0 127.0.0.53:53 0.0.0.0:* 10119386 632/systemd-resolve On Tue, Feb 15, 2022 at 3:49 PM Blake McBride wrote: > Thanks, Neil, > > I started up tomcat and ran: curl http://localhost:8080 > > It returned the page. Great. > > I then ran: ./shutdown.sh > > It stopped just fine. I checked with ps. > > I then did ./startup.sh again. > > This time the curl command just hung and ./shutdown.sh gave me "Connection > refused" error. > > catalina.out shows no errors. > > Thanks! > > Blake > > > On Tue, Feb 15, 2022 at 3:42 PM Neil Aggarwal > wrote: > >> Use something like lynx or curl from the command line to >> try to connect to the Tomcat instance. >> >> Thank you, >> Neil >> >> -- >> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com >> We offer 30 year loans on single family houses! >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: Can't stop tomcat - connection refused
Thanks, Neil, I started up tomcat and ran: curl http://localhost:8080 It returned the page. Great. I then ran: ./shutdown.sh It stopped just fine. I checked with ps. I then did ./startup.sh again. This time the curl command just hung and ./shutdown.sh gave me "Connection refused" error. catalina.out shows no errors. Thanks! Blake On Tue, Feb 15, 2022 at 3:42 PM Neil Aggarwal wrote: > Use something like lynx or curl from the command line to > try to connect to the Tomcat instance. > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Can't stop tomcat - connection refused
Use something like lynx or curl from the command line to try to connect to the Tomcat instance. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't stop tomcat - connection refused
Thanks, Neil, Catalina.out shows a normal startup with no errors. It's the default config. I am not adding, changing, or deleting any files from the normal tomcat distro. Also, I am doing everything as root. I didn't try connecting locally mainly because I'm on a server. No GUI. The fact that I get "Connection refused" locally when I try to shutdown is about the only indication I have that something is wrong. Thanks! Blake On Tue, Feb 15, 2022 at 3:12 PM Neil Aggarwal wrote: > Maybe better to back up one more step: > > Are you sure Tomcat started up correctly? > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Can't stop tomcat - connection refused
Maybe better to back up one more step: Are you sure Tomcat started up correctly? Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Can't stop tomcat - connection refused
> I cannot connect to tomcat (port 8080) externally Can you connect to it from the local machine? If that is the case, it may be only listening for local connections. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Can't stop tomcat - connection refused
Greetings, I have been running tomcat for more than ten years. Today, I tried to change VPS providers. I created a Ubuntu server, added Java 8, and installed tomcat 9.0.58. I made no configuration or other changes. I simply unzipped tomcat and started it up. I have no firewall running and I can ssh into the machine. I cannot connect to tomcat (port 8080) externally. And, when I attempt to shutdown tomcat via ./shutdown.sh I get "Connection refused". I tried the exact same sequence on my old VPS provider. It worked first time. The new provider is one of the top-tier providers. I shouldn't be having such a problem. I have put in a ticket with the provider but I thought someone on this list might say "did you try X?" I appreciate any suggestions. Thanks! Blake McBride
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Stefan,
Now I got it. Thanks for the clarification :)
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Thomas,
Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
>
> by spec / RFC, a HEAD request is not allowed to return any body.
>
> Greetings,
> Thomas
This is true and that is why i'm writing to this list. In the described case
mod_jk returns a response body although it should not (at least i think mod_jk
is somehow responsible for that)
> -Ursprüngliche Nachricht-
> Von: Stefan Mayr
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD
> request
>
> Hello again,
>
> a self-compiled mod_jk 1.2.48 shows the same issue.
>
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the
>> source comment my understanding is, that for both variants a HEAD
>> request (by definition must have an empty response body) should let
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
>
> Although this looks different on the first glance it seems to be the same.
>
>> The response only seems correct for variant 1 - which is configured
>> to let Apache httpd handle all responses for status codes >= 401. For
>> variant 2 mod_jk seems to handle the response itself - contrary to
>> what the comment explains.
>
> This leads to the next assumption, that whenever there is a special handling
> for use_server_errors there should be something similar for the case with an
> empty/non-existing response body.
>
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
>
> if (!r->something_like_bodyct && r->http_response_status >=
> JK_HTTP_BAD_REQUEST){
> r->response_blocked = JK_TRUE;
> }
>
> Adding code like this (sorry, i could not find out how to determine if there
> is a response body) fixes the issue with the wrong response body for a HEAD
> request. But we miss the WWW-Authenticate header now.
>
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP
> Unauthorized. But again, only for use_server_errors.
>
> This should be fixable by extending the condition like this
>
> if ((s->extension.use_server_error_pages &&
> status >= s->extension.use_server_error_pages) ||
> (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
>
>
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
>
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an
>>> application running in the Tomcat server. The requests contain an
>>> Authorization header for Basic authentication. Expected response is
>>> a HTTP 200 OK or HTTP 401 if this particular user is not allowed to
>>> access that ressource. Because this is a HEAD request there must not
>>> be a response body according to RFC 2616.
>>>
>>> If there is a response body in the response to the HEAD request our
>>> loadbalancer does strange things: aborts the connection if the
>>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
>>> issue on its own which we might have to solve with the vendor.
>>>
>>> Now comes the point where I need your help. We have a httpd
>>> configuration with mod_jk which generates these invalid response
>>> bodies on HEAD requests. I have a gut feeling this could be a bug
>>> with mod_jk.
>>>
>>> For demonstration purpose i created a minimal demo app which only is
>>> a WEB-INF/web.xml >> xmlns="https://jakarta.ee/xml/ns/jakartaee;
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>> xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>>
>>>
Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Thomas,
Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
Hello Stefan,
by spec / RFC, a HEAD request is not allowed to return any body.
Greetings,
Thomas
This is true and that is why i'm writing to this list. In the described
case mod_jk returns a response body although it should not (at least i
think mod_jk is somehow responsible for that)
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello again,
a self-compiled mod_jk 1.2.48 shows the same issue.
Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
Hi,
looking at the source code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
0/mod_jk.c#L2954#L2973
I did some more testing:
Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker
ignoring what variant 2 changes for regular request: reading the
source comment my understanding is, that for both variants a HEAD
request (by definition must have an empty response body) should let
Apache httpd handle the error code.
But the return code for jk_handler looks different:
Variant 1: s.http_response_status
Variant 2: r->status
Although this looks different on the first glance it seems to be the same.
The response only seems correct for variant 1 - which is configured to
let Apache httpd handle all responses for status codes >= 401. For
variant 2 mod_jk seems to handle the response itself - contrary to
what the comment explains.
This leads to the next assumption, that whenever there is a special handling
for use_server_errors there should be something similar for the case with an
empty/non-existing response body.
There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like
if (!r->something_like_bodyct && r->http_response_status >=
JK_HTTP_BAD_REQUEST){
r->response_blocked = JK_TRUE;
}
Adding code like this (sorry, i could not find out how to determine if there is
a response body) fixes the issue with the wrong response body for a HEAD
request. But we miss the WWW-Authenticate header now.
Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for
use_server_errors.
This should be fixable by extending the condition like this
if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.
Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
Hello Tomcat users,
this week we were debugging a strange connection issue which I
tracked down to an interference between Apache httpd and mod_jk.
For the full picture, the infrastructure setup contains
1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
mit AJP-Connector
We have an application doing many different HEAD requests against an
application running in the Tomcat server. The requests contain an
Authorization header for Basic authentication. Expected response is a
HTTP 200 OK or HTTP 401 if this particular user is not allowed to
access that ressource. Because this is a HEAD request there must not
be a response body according to RFC 2616.
If there is a response body in the response to the HEAD request our
loadbalancer does strange things: aborts the connection if the
clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
issue on its own which we might have to solve with the vendor.
Now comes the point where I need your help. We have a httpd
configuration with mod_jk which generates these invalid response
bodies on HEAD requests. I have a gut feeling this could be a bug
with mod_jk.
For demonstration purpose i created a minimal demo app which only is
a WEB-INF/web.xml https://jakarta.ee/xml/ns/jakartaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
version="5.0">
Login
/*
manager
manager
BASIC
Then I place a JkMount in my Apache httpd configuration (+ minimal
worker.properties):
JkMount /demo/* ajp13_worker
Testing this with curl works like expected:
root@1ae8973f1b6b:~# curl -I -v localhost/demo/
* Trying 127.0.0.1:80...
*
AW: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello Stefan,
by spec / RFC, a HEAD request is not allowed to return any body.
Greetings,
Thomas
-Ursprüngliche Nachricht-
Von: Stefan Mayr
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request
Hello again,
a self-compiled mod_jk 1.2.48 shows the same issue.
Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
> Hi,
>
> looking at the source code
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L2954#L2973
> I did some more testing:
>
> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
> Variant 2: JkMount /demo/* ajp13_worker
>
> ignoring what variant 2 changes for regular request: reading the
> source comment my understanding is, that for both variants a HEAD
> request (by definition must have an empty response body) should let
> Apache httpd handle the error code.
>
> But the return code for jk_handler looks different:
>
> Variant 1: s.http_response_status
> Variant 2: r->status
Although this looks different on the first glance it seems to be the same.
> The response only seems correct for variant 1 - which is configured to
> let Apache httpd handle all responses for status codes >= 401. For
> variant 2 mod_jk seems to handle the response itself - contrary to
> what the comment explains.
This leads to the next assumption, that whenever there is a special handling
for use_server_errors there should be something similar for the case with an
empty/non-existing response body.
There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like
if (!r->something_like_bodyct && r->http_response_status >=
JK_HTTP_BAD_REQUEST){
r->response_blocked = JK_TRUE;
}
Adding code like this (sorry, i could not find out how to determine if there is
a response body) fixes the issue with the wrong response body for a HEAD
request. But we miss the WWW-Authenticate header now.
Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for
use_server_errors.
This should be fixable by extending the condition like this
if ((s->extension.use_server_error_pages &&
status >= s->extension.use_server_error_pages) ||
(!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
But the WWW-Authenticate header is still missing. So i'm wrong, again.
Although it feels like i'm close.
> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>> Hello Tomcat users,
>>
>> this week we were debugging a strange connection issue which I
>> tracked down to an interference between Apache httpd and mod_jk.
>>
>> For the full picture, the infrastructure setup contains
>>
>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat
>> mit AJP-Connector
>>
>> We have an application doing many different HEAD requests against an
>> application running in the Tomcat server. The requests contain an
>> Authorization header for Basic authentication. Expected response is a
>> HTTP 200 OK or HTTP 401 if this particular user is not allowed to
>> access that ressource. Because this is a HEAD request there must not
>> be a response body according to RFC 2616.
>>
>> If there is a response body in the response to the HEAD request our
>> loadbalancer does strange things: aborts the connection if the
>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an
>> issue on its own which we might have to solve with the vendor.
>>
>> Now comes the point where I need your help. We have a httpd
>> configuration with mod_jk which generates these invalid response
>> bodies on HEAD requests. I have a gut feeling this could be a bug
>> with mod_jk.
>>
>> For demonstration purpose i created a minimal demo app which only is
>> a WEB-INF/web.xml > xmlns="https://jakarta.ee/xml/ns/jakartaee;
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>
>> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>> version="5.0">
>>
>>
>> Login
>> /*
>>
>>
>> manager
>>
>>
>>
>> manager
>>
>>
>> BASIC
>>
>>
>>
>> Then I place a JkMount in my Apache httpd configuration (+ minimal
>> worker.properties):
>>
>> JkMount /demo/* ajp13_worker
>>
>> Testing this with curl works like expected:
>>
>> root@1ae8973f1b6b:~# curl -I -v localhost/demo/
>> * Trying 127.0.0.1:80...
>> * TCP_NODELAY set
>> * Connected to localhost (127.0.0.1)
