You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Flynn, Peter" <pf...@ucc.ie> on 2017/07/24 10:12:08 UTC
Server giving 404 since upgrade to Tomcat7
I have a CentOS7 server running Apache and Tomcat serving the Cocoon application which handles lots of research project XML pages. It's been running fine for years, through Tomcat and Apache updates. My system owners updated the server to Tomcat7 over the weekend and all Tomcat pages re now coming up as 404 Not Found. As a temporary fix we have restored service from backup on another VM.
The update was done using the version of Tomcat from the CentOS7 repos because it is the policy to use the repos only, and I can't change it. It's never been a problem before: Cocoon is the only webapp in use, and we have been running this configuration successfully since the days of Red Hat and Cocoon 1.
404 implies that Tomcat simply can't find the files/directories, but it's a plain Tomcat error page, not an application error, and there is no indication of where it looked to find stuff. As it's a Tomcat error, not a Cocoon error, and it's the same error for every page, I am assuming it is a config error and that Tomcat can't actually find anything at all.
The previous config files are all correctly in place in /etc/tomcat, and the user data is all untouched, and the Cocoon application is where it always was at /var/lib/tomcat/webapps.
The tomcat user account (in /etc/passwd) has its home at /usr/share/tomcat (I know, don't ask), and there are (correctly) soft links to webapps, work, lib, logs, temp, and conf all pointing to the right places.
I went through the upgrade document at https://tomcat.apache.org/migration-7.html and applied the changes to attributes on <Host> and <Context> but after a restart there was no change. As this is a single instance, single application, and no bells or whistles, and Tomcat clearly starts up OK (Catalina.out says so :-) I am naively assuming that it's "just" a configuration issue.
However, in tomcat.conf there is a setting for TOMCATS_BASE="/var/lib/tomcats" (plural), which I have never used (it was there in earlier versions too). That directory is empty. The comment above the setting says:
# In new-style instances, if CATALINA_BASE isn't specified, it will
# be constructed by joining TOMCATS_BASE and NAME.
However, it fails to specify what NAME is or should be. There is no CATALINA_BASE in this file (nor was there in earlier versions: where is it defined?). Declaring CATALINA_BASE="/var/lib/tomcat" and restarting Tomcat changes the error message to the Apache one-liner "temporarily unable to service your request", and the Apache logs for the virtual hosts we serve do indeed show lots of these:
(111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed
AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s
[proxy_ajp:error] [pid 15285] [client aaa.bbb.ccc.ddd:16543] AH00896: failed to make connection to backend: localhost
I'm now going to start trawling the logs for hints as to why Tomcat has lost track of where it should look for the application. Any suggestions would be warmly received.
(Yes, I know we should be installing Tomcat from source: I have been arguing this case unsuccessfully for many years :-( but this is a state-funded university, so we don't have corporate levels of funding or people to be able to hand-build everything.)
///Peter
Re: Server giving 404 since upgrade to Tomcat7
Posted by "Flynn, Peter" <pf...@ucc.ie>.
Thanks very much. Apologies for top-posting but I'm using a phone mail client. I'm away at a conference until the 8th so I'll do this when I return.
///Peter
On 25 July 2017 20:00:50 Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 7/25/17 11:14 AM, Peter Flynn wrote:
>> On 24/07/17 11:57, Mark Thomas wrote:
>>> On 24/07/17 11:12, Flynn, Peter wrote:
>>
>> I must apologise first for unintentionally misleading you: the
>> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I
>> inherited this along with what was clearly bad information.
>
> Thanks for the clarification.
>
>>> Running from a package tends to limit the members of this that
>>> are available to help to those that understand the packaging on
>>> the platform in question.
>>
>> I'm afraid so. But I hope this is not about packaging, but about
>> modifying the configuration.
>
> Probably so, especially because it was a minor version upgrade.
>
>>> Tomcat needs allowLinking to be correctly set if that path to a
>>> web application (or the web application itself) uses symlinks. I
>>> don't think that has changed between 6.0.x and 7.0.x.
>>
>> There seem to be two, but I have never used or touched examples.
>>
>> # find /var/lib/tomcat/webapps -type l -ls 536929726 0
>> lrwxrwxrwx 1 tomcat tomcat 40 Aug 11 2016
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar ->
>> /usr/share/java/jakarta-taglibs-core.jar 536929727 0 lrwxrwxrwx
>> 1 tomcat tomcat 44 Aug 11 2016
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar ->
>> /usr/share/java/jakarta-taglibs-standard.jar
>
> That looks like the package manager's doing, and is probably okay. If
> it's not okay, then complain to the package manager that they have
> broken their own package :) (And the package manager happens to be
> reading this thread, so you should be good, here.)
>
>>>> # In new-style instances, if CATALINA_BASE isn't specified, it
>>>> will # be constructed by joining TOMCATS_BASE and NAME.
>>>
>>> Those last two variables are package specific.
>>
>> What is a 'package' in this context? A Tomcat application?
>
> Mark was referring to the Tomcat "package" as packaged by the package
> manager (e.g. yum).
>
> In this case, Tomcat itself doesn't do anything with environment
> variables called TOMCAT_HOME or NAME. Tomcat only cares about
> CATALINA_BASE (where instance-specific configuration and webapps are
> kept) and CATALINA_HOME (which is where the base Tomcat files can be
> found).
>
>>> The Tomcat logs should at least tell you what - if anything -
>>> Tomcat is deploying.
>>
>> If I can make sense of them...
>>
>>> There is no one 'right' way to install Tomcat. Pick the one that
>>> works best for you (and be prepared to try an alternative if you
>>> hit problems).
>>
>> :-) I'd rather compile from scratch, but that's just the way I was
>> brought up.
>
> Building Tomcat from source is a waste of your time: the official
> packages (both from ASF and from Red Hat) have all been built for you
> and are environment agnostic. I would never recommend that anyone
> build Tomcat themselves unless they are trying to hack on it for their
> own needs.
>
> Let's try this:
>
> 1. Stop Tomcat and remove all log files (or push them somewhere else
> out of the way)
> 2. Launch Tomcat (and please tell us how you do that)
> 3. Make a single request that returns 404 but should not
> 4. Stop Tomcat
> 5. Post the contents of logs/catalina.out to the list
>
> Please remove any secrets that might be in that file (the only secrets
> that might be in there would be coming from your application).
>
> I saw your log file snippets, but there might be something you missed
> (since the log was incomplete).
>
> I've used Apache Cocoon with Tomcat 4.x and later and haven't had any
> problems like you describe. I suspect this is a simple configuration
> problem that we can help you get corrected.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZd5VXAAoJEBzwKT+lPKRY0i8QAKdDAO9Dx+ilxET2wuRNiJCy
> IQkjVcc1T5GPxNWpdIJIA/i8+5lhsUT6+BJy77hEsIjAfeGIAXbywylMUAv/i/Oo
> Ixgwb+NkzZ38dW14b8Y+QmtJ2qP/aM9q1TvlxS9/AxIk+sT7dl6jQucZsYM1NqSI
> HgGwqXtgvs3Rzzcq+0SNqDrDVsEW486cCFqnw8pboCYAGzUkpLY2zOApjQLD30cR
> U7DrGgYNzThcXngusKFuK2AWU6DDx0mIkKFxArtXWLFJr0prk4pM+BWdXQH8FGac
> kdX/pu7ryaCjeQ/QztWGHsA4W9CplRlCTxhWRIQwiY86auwYGis55yVZ1jzuXGdi
> IY17e3Sdnmo8GFjfTaUSxJIpquRW/+GqApe/yia2vL1Vr6Pbztu/7IMxEw13iHfF
> eyvY9haDBFrdrvINBtAj8FW5K8WL41PAaHsXV5R67nMyx2yQ0Nd/G/aXFikrqn4R
> T8tQNfyTt2ZaExsySU4oNSpejSjAolRX8AqvS7/aexEN+zRC3MePNOgS6AuuxBEe
> 7LIe3Si0JW7+2gYShgCYMPSK5w7fJzGJrHqbTlJPlqf38w2bj511s4K9fKYsbPcp
> PkkYAlGSU3tn53gk4crbOSjceGEWZKj4byvvldSjDyG3NdhMrjjQI8C7+fYXSqBI
> d39WE9U7+Dqt1Fi+gJYC
> =NjvT
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server giving 404 since upgrade to Tomcat7
Posted by Peter Kreuser <lo...@kreuser.name>.
Hi all,
> Am 25.07.2017 um 21:00 schrieb Christopher Schultz <ch...@christopherschultz.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
>>> On 7/25/17 11:14 AM, Peter Flynn wrote:
>>> On 24/07/17 11:57, Mark Thomas wrote:
>>> On 24/07/17 11:12, Flynn, Peter wrote:
>>
>> I must apologise first for unintentionally misleading you: the
>> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I
>> inherited this along with what was clearly bad information.
>
> Thanks for the clarification.
>
>>> Running from a package tends to limit the members of this that
>>> are available to help to those that understand the packaging on
>>> the platform in question.
>>
>> I'm afraid so. But I hope this is not about packaging, but about
>> modifying the configuration.
>
> Probably so, especially because it was a minor version upgrade.
>
>>> Tomcat needs allowLinking to be correctly set if that path to a
>>> web application (or the web application itself) uses symlinks. I
>>> don't think that has changed between 6.0.x and 7.0.x.
>>
>> There seem to be two, but I have never used or touched examples.
>>
>> # find /var/lib/tomcat/webapps -type l -ls 536929726 0
>> lrwxrwxrwx 1 tomcat tomcat 40 Aug 11 2016
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar ->
>> /usr/share/java/jakarta-taglibs-core.jar 536929727 0 lrwxrwxrwx
>> 1 tomcat tomcat 44 Aug 11 2016
>> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar ->
>> /usr/share/java/jakarta-taglibs-standard.jar
>
> That looks like the package manager's doing, and is probably okay. If
> it's not okay, then complain to the package manager that they have
> broken their own package :) (And the package manager happens to be
> reading this thread, so you should be good, here.)
>
>>>> # In new-style instances, if CATALINA_BASE isn't specified, it
>>>> will # be constructed by joining TOMCATS_BASE and NAME.
>>>
>>> Those last two variables are package specific.
>>
>> What is a 'package' in this context? A Tomcat application?
>
> Mark was referring to the Tomcat "package" as packaged by the package
> manager (e.g. yum).
>
> In this case, Tomcat itself doesn't do anything with environment
> variables called TOMCAT_HOME or NAME. Tomcat only cares about
> CATALINA_BASE (where instance-specific configuration and webapps are
> kept) and CATALINA_HOME (which is where the base Tomcat files can be
> found).
>
>>> The Tomcat logs should at least tell you what - if anything -
>>> Tomcat is deploying.
>>
>> If I can make sense of them...
>>
>>> There is no one 'right' way to install Tomcat. Pick the one that
>>> works best for you (and be prepared to try an alternative if you
>>> hit problems).
>>
>> :-) I'd rather compile from scratch, but that's just the way I was
>> brought up.
>
> Building Tomcat from source is a waste of your time: the official
> packages (both from ASF and from Red Hat) have all been built for you
> and are environment agnostic. I would never recommend that anyone
> build Tomcat themselves unless they are trying to hack on it for their
> own needs.
>
> Let's try this:
>
> 1. Stop Tomcat and remove all log files (or push them somewhere else
> out of the way)
> 2. Launch Tomcat (and please tell us how you do that)
> 3. Make a single request that returns 404 but should not
> 4. Stop Tomcat
> 5. Post the contents of logs/catalina.out to the list
>
> Please remove any secrets that might be in that file (the only secrets
> that might be in there would be coming from your application).
>
> I saw your log file snippets, but there might be something you missed
> (since the log was incomplete).
>
> I've used Apache Cocoon with Tomcat 4.x and later and haven't had any
> problems like you describe. I suspect this is a simple configuration
> problem that we can help you get corrected.
>
> - -chris
All started contexts are from a default install. ROOT may be also the default homepage, so that would explain the 404s.
Maybe the new installation is using a different than expected webapps dir?! Or has overwritten your ROOT?
I would try to remove all webapps (besides manager), restart tomcat and see what's in the logs. (That's best practise anyways to remove samples and the default ROOT).
BTW: from the logs I see a misconfigured server/context.xml as tomcat warns that xml attributes are used that have no corresponding setters!?
Best regards
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server giving 404 since upgrade to Tomcat7
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter,
On 7/25/17 11:14 AM, Peter Flynn wrote:
> On 24/07/17 11:57, Mark Thomas wrote:
>> On 24/07/17 11:12, Flynn, Peter wrote:
>
> I must apologise first for unintentionally misleading you: the
> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I
> inherited this along with what was clearly bad information.
Thanks for the clarification.
>> Running from a package tends to limit the members of this that
>> are available to help to those that understand the packaging on
>> the platform in question.
>
> I'm afraid so. But I hope this is not about packaging, but about
> modifying the configuration.
Probably so, especially because it was a minor version upgrade.
>> Tomcat needs allowLinking to be correctly set if that path to a
>> web application (or the web application itself) uses symlinks. I
>> don't think that has changed between 6.0.x and 7.0.x.
>
> There seem to be two, but I have never used or touched examples.
>
> # find /var/lib/tomcat/webapps -type l -ls 536929726 0
> lrwxrwxrwx 1 tomcat tomcat 40 Aug 11 2016
> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar ->
> /usr/share/java/jakarta-taglibs-core.jar 536929727 0 lrwxrwxrwx
> 1 tomcat tomcat 44 Aug 11 2016
> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar ->
> /usr/share/java/jakarta-taglibs-standard.jar
That looks like the package manager's doing, and is probably okay. If
it's not okay, then complain to the package manager that they have
broken their own package :) (And the package manager happens to be
reading this thread, so you should be good, here.)
>>> # In new-style instances, if CATALINA_BASE isn't specified, it
>>> will # be constructed by joining TOMCATS_BASE and NAME.
>>
>> Those last two variables are package specific.
>
> What is a 'package' in this context? A Tomcat application?
Mark was referring to the Tomcat "package" as packaged by the package
manager (e.g. yum).
In this case, Tomcat itself doesn't do anything with environment
variables called TOMCAT_HOME or NAME. Tomcat only cares about
CATALINA_BASE (where instance-specific configuration and webapps are
kept) and CATALINA_HOME (which is where the base Tomcat files can be
found).
>> The Tomcat logs should at least tell you what - if anything -
>> Tomcat is deploying.
>
> If I can make sense of them...
>
>> There is no one 'right' way to install Tomcat. Pick the one that
>> works best for you (and be prepared to try an alternative if you
>> hit problems).
>
> :-) I'd rather compile from scratch, but that's just the way I was
> brought up.
Building Tomcat from source is a waste of your time: the official
packages (both from ASF and from Red Hat) have all been built for you
and are environment agnostic. I would never recommend that anyone
build Tomcat themselves unless they are trying to hack on it for their
own needs.
Let's try this:
1. Stop Tomcat and remove all log files (or push them somewhere else
out of the way)
2. Launch Tomcat (and please tell us how you do that)
3. Make a single request that returns 404 but should not
4. Stop Tomcat
5. Post the contents of logs/catalina.out to the list
Please remove any secrets that might be in that file (the only secrets
that might be in there would be coming from your application).
I saw your log file snippets, but there might be something you missed
(since the log was incomplete).
I've used Apache Cocoon with Tomcat 4.x and later and haven't had any
problems like you describe. I suspect this is a simple configuration
problem that we can help you get corrected.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZd5VXAAoJEBzwKT+lPKRY0i8QAKdDAO9Dx+ilxET2wuRNiJCy
IQkjVcc1T5GPxNWpdIJIA/i8+5lhsUT6+BJy77hEsIjAfeGIAXbywylMUAv/i/Oo
Ixgwb+NkzZ38dW14b8Y+QmtJ2qP/aM9q1TvlxS9/AxIk+sT7dl6jQucZsYM1NqSI
HgGwqXtgvs3Rzzcq+0SNqDrDVsEW486cCFqnw8pboCYAGzUkpLY2zOApjQLD30cR
U7DrGgYNzThcXngusKFuK2AWU6DDx0mIkKFxArtXWLFJr0prk4pM+BWdXQH8FGac
kdX/pu7ryaCjeQ/QztWGHsA4W9CplRlCTxhWRIQwiY86auwYGis55yVZ1jzuXGdi
IY17e3Sdnmo8GFjfTaUSxJIpquRW/+GqApe/yia2vL1Vr6Pbztu/7IMxEw13iHfF
eyvY9haDBFrdrvINBtAj8FW5K8WL41PAaHsXV5R67nMyx2yQ0Nd/G/aXFikrqn4R
T8tQNfyTt2ZaExsySU4oNSpejSjAolRX8AqvS7/aexEN+zRC3MePNOgS6AuuxBEe
7LIe3Si0JW7+2gYShgCYMPSK5w7fJzGJrHqbTlJPlqf38w2bj511s4K9fKYsbPcp
PkkYAlGSU3tn53gk4crbOSjceGEWZKj4byvvldSjDyG3NdhMrjjQI8C7+fYXSqBI
d39WE9U7+Dqt1Fi+gJYC
=NjvT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server giving 404 since upgrade to Tomcat7
Posted by Peter Flynn <pf...@ucc.ie>.
On 24/07/17 11:57, Mark Thomas wrote:
> On 24/07/17 11:12, Flynn, Peter wrote:
I must apologise first for unintentionally misleading you: the upgrade
was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I inherited this
along with what was clearly bad information.
> Running from a package tends to limit the members of this that are
> available to help to those that understand the packaging on the
> platform in question.
I'm afraid so. But I hope this is not about packaging, but about
modifying the configuration.
> Tomcat needs allowLinking to be correctly set if that path to a web
> application (or the web application itself) uses symlinks. I don't think
> that has changed between 6.0.x and 7.0.x.
There seem to be two, but I have never used or touched examples.
# find /var/lib/tomcat/webapps -type l -ls
536929726 0 lrwxrwxrwx 1 tomcat tomcat 40 Aug 11 2016
/var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar ->
/usr/share/java/jakarta-taglibs-core.jar
536929727 0 lrwxrwxrwx 1 tomcat tomcat 44 Aug 11 2016
/var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar ->
/usr/share/java/jakarta-taglibs-standard.jar
>> # In new-style instances, if CATALINA_BASE isn't specified, it will
>> # be constructed by joining TOMCATS_BASE and NAME.
>
> Those last two variables are package specific.
What is a 'package' in this context? A Tomcat application?
> The Tomcat logs should at least tell you what - if anything - Tomcat is
> deploying.
If I can make sense of them...
> There is no one 'right' way to install Tomcat. Pick the one that works
> best for you (and be prepared to try an alternative if you hit problems).
:-) I'd rather compile from scratch, but that's just the way I was
brought up.
On 24/07/17 14:50, Coty Sutherland wrote:
[...]
> In my experience, a 404 after an update (with no other application
> changes) suggests that the application failed deployment. Can you
> verify that you don't see any exceptions in your log?
I would if I knew what to look for :-) In /var/log/tomcat there are:
• a catalina.out but it's empty
• hundreds of host-manager.yyyy-mm-yy.log, all empty
• hundreds of localhost.yyyy-mm-yy.log, all empty
• hundreds of localhost_access_log.yyyy-mm-dd.txt, between 10–20MB each
• dozens of catalina.out-yyyymmdd.gz, 20 or so bytes each
• dozens of catalina.yyyy-mm-dd.log, 30-100KB each
• one catalina.out, empty
I realise this is probably CentOS's or RedHat's doing :-)
A typical catalina.yyyy-mm-dd.log starts with
> Jul 25, 2017 7:55:01 AM org.apache.catalina.core.StandardServer await
> INFO: A valid shutdown command was received via the shutdown port. Stopping the Server ins
> tance.
> Jul 25, 2017 7:55:01 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> Jul 25, 2017 7:55:05 AM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal performance in produ
> ction environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/u
> sr/lib64:/lib64:/lib:/usr/lib
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["http-bio-8080"]
> Jul 25, 2017 7:55:05 AM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
> Jul 25, 2017 7:55:05 AM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 586 ms
> Jul 25, 2017 7:55:05 AM org.apache.catalina.core.StandardService startInternal
> INFO: Starting service Catalina
and eventually gets round to
> Jul 25, 2017 7:55:30 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 25398 ms
and it includes
> INFO: Deployment of web application directory /var/lib/tomcat/webapps/examples has finished in 1,019 ms
> INFO: Deployment of web application directory /var/lib/tomcat/webapps/sample has finished in 299 ms
> INFO: Deployment of web application directory /var/lib/tomcat/webapps/host-manager has finished in 259 ms
> INFO: Deployment of web application directory /var/lib/tomcat/webapps/manager has finished in 244 ms
> INFO: Deployment of web application directory /var/lib/tomcat/webapps/ROOT has finished in 9,396 ms
So it appears to have found ROOT (which contains my Cocoon stuff) and
deployed it. But all the URIs come back with a Tomcat 404, which is why
I think that this version of Tomcat is interpreting the config
differently (or missing some expected attribute), as the config was
untouched between before and after.
///Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server giving 404 since upgrade to Tomcat7
Posted by Coty Sutherland <cs...@redhat.com>.
On Mon, Jul 24, 2017 at 6:57 AM, Mark Thomas <ma...@apache.org> wrote:
> On 24/07/17 11:12, Flynn, Peter wrote:
>> I have a CentOS7 server running Apache and Tomcat serving the Cocoon application which handles lots of research project XML pages. It's been running fine for years, through Tomcat and Apache updates. My system owners updated the server to Tomcat7 over the weekend and all Tomcat pages re now coming up as 404 Not Found. As a temporary fix we have restored service from backup on another VM.
>>
>> The update was done using the version of Tomcat from the CentOS7 repos because it is the policy to use the repos only, and I can't change it. It's never been a problem before: Cocoon is the only webapp in use, and we have been running this configuration successfully since the days of Red Hat and Cocoon 1.
>
> Running from a package tends to limit the members of this that are
> available to help to those that understand the packaging on the platform
> in question.
>
> If you could provide exact Tomcat versions for before and after the
> upgrade that would help.
>
>> 404 implies that Tomcat simply can't find the files/directories, but it's a plain Tomcat error page, not an application error, and there is no indication of where it looked to find stuff. As it's a Tomcat error, not a Cocoon error, and it's the same error for every page, I am assuming it is a config error and that Tomcat can't actually find anything at all.
>>
>> The previous config files are all correctly in place in /etc/tomcat, and the user data is all untouched, and the Cocoon application is where it always was at /var/lib/tomcat/webapps.
>>
>> The tomcat user account (in /etc/passwd) has its home at /usr/share/tomcat (I know, don't ask), and there are (correctly) soft links to webapps, work, lib, logs, temp, and conf all pointing to the right places.
>
> Tomcat needs allowLinking to be correctly set if that path to a web
> application (or the web application itself) uses symlinks. I don't think
> that has changed between 6.0.x and 7.0.x.
>
>> I went through the upgrade document at https://tomcat.apache.org/migration-7.html and applied the changes to attributes on <Host> and <Context> but after a restart there was no change. As this is a single instance, single application, and no bells or whistles, and Tomcat clearly starts up OK (Catalina.out says so :-) I am naively assuming that it's "just" a configuration issue.
>>
>> However, in tomcat.conf there is a setting for TOMCATS_BASE="/var/lib/tomcats" (plural), which I have never used (it was there in earlier versions too). That directory is empty. The comment above the setting says:
>>
>> # In new-style instances, if CATALINA_BASE isn't specified, it will
>> # be constructed by joining TOMCATS_BASE and NAME.
>
> Those last two variables are package specific.
>
>> However, it fails to specify what NAME is or should be. There is no CATALINA_BASE in this file (nor was there in earlier versions: where is it defined?). Declaring CATALINA_BASE="/var/lib/tomcat" and restarting Tomcat changes the error message to the Apache one-liner "temporarily unable to service your request", and the Apache logs for the virtual hosts we serve do indeed show lots of these:
>>
>> (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed
>> AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s
>> [proxy_ajp:error] [pid 15285] [client aaa.bbb.ccc.ddd:16543] AH00896: failed to make connection to backend: localhost
>>
>> I'm now going to start trawling the logs for hints as to why Tomcat has lost track of where it should look for the application. Any suggestions would be warmly received.
In my experience, a 404 after an update (with no other application
changes) suggests that the application failed deployment. Can you
verify that you don't see any exceptions in your log?
> The Tomcat logs should at least tell you what - if anything - Tomcat is
> deploying.
>
>> (Yes, I know we should be installing Tomcat from source: I have been arguing this case unsuccessfully for many years :-( but this is a state-funded university, so we don't have corporate levels of funding or people to be able to hand-build everything.)
>
> There are pros and cons to every installation method. Installing from
> the OS packages usually makes things easier but it can make it a little
> harder to get help when things go wrong.
>
> There is no one 'right' way to install Tomcat. Pick the one that works
> best for you (and be prepared to try an alternative if you hit problems).
+1 :)
>
>
>>
>> ///Peter
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server giving 404 since upgrade to Tomcat7
Posted by Mark Thomas <ma...@apache.org>.
On 24/07/17 11:12, Flynn, Peter wrote:
> I have a CentOS7 server running Apache and Tomcat serving the Cocoon application which handles lots of research project XML pages. It's been running fine for years, through Tomcat and Apache updates. My system owners updated the server to Tomcat7 over the weekend and all Tomcat pages re now coming up as 404 Not Found. As a temporary fix we have restored service from backup on another VM.
>
> The update was done using the version of Tomcat from the CentOS7 repos because it is the policy to use the repos only, and I can't change it. It's never been a problem before: Cocoon is the only webapp in use, and we have been running this configuration successfully since the days of Red Hat and Cocoon 1.
Running from a package tends to limit the members of this that are
available to help to those that understand the packaging on the platform
in question.
If you could provide exact Tomcat versions for before and after the
upgrade that would help.
> 404 implies that Tomcat simply can't find the files/directories, but it's a plain Tomcat error page, not an application error, and there is no indication of where it looked to find stuff. As it's a Tomcat error, not a Cocoon error, and it's the same error for every page, I am assuming it is a config error and that Tomcat can't actually find anything at all.
>
> The previous config files are all correctly in place in /etc/tomcat, and the user data is all untouched, and the Cocoon application is where it always was at /var/lib/tomcat/webapps.
>
> The tomcat user account (in /etc/passwd) has its home at /usr/share/tomcat (I know, don't ask), and there are (correctly) soft links to webapps, work, lib, logs, temp, and conf all pointing to the right places.
Tomcat needs allowLinking to be correctly set if that path to a web
application (or the web application itself) uses symlinks. I don't think
that has changed between 6.0.x and 7.0.x.
> I went through the upgrade document at https://tomcat.apache.org/migration-7.html and applied the changes to attributes on <Host> and <Context> but after a restart there was no change. As this is a single instance, single application, and no bells or whistles, and Tomcat clearly starts up OK (Catalina.out says so :-) I am naively assuming that it's "just" a configuration issue.
>
> However, in tomcat.conf there is a setting for TOMCATS_BASE="/var/lib/tomcats" (plural), which I have never used (it was there in earlier versions too). That directory is empty. The comment above the setting says:
>
> # In new-style instances, if CATALINA_BASE isn't specified, it will
> # be constructed by joining TOMCATS_BASE and NAME.
Those last two variables are package specific.
> However, it fails to specify what NAME is or should be. There is no CATALINA_BASE in this file (nor was there in earlier versions: where is it defined?). Declaring CATALINA_BASE="/var/lib/tomcat" and restarting Tomcat changes the error message to the Apache one-liner "temporarily unable to service your request", and the Apache logs for the virtual hosts we serve do indeed show lots of these:
>
> (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed
> AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s
> [proxy_ajp:error] [pid 15285] [client aaa.bbb.ccc.ddd:16543] AH00896: failed to make connection to backend: localhost
>
> I'm now going to start trawling the logs for hints as to why Tomcat has lost track of where it should look for the application. Any suggestions would be warmly received.
The Tomcat logs should at least tell you what - if anything - Tomcat is
deploying.
> (Yes, I know we should be installing Tomcat from source: I have been arguing this case unsuccessfully for many years :-( but this is a state-funded university, so we don't have corporate levels of funding or people to be able to hand-build everything.)
There are pros and cons to every installation method. Installing from
the OS packages usually makes things easier but it can make it a little
harder to get help when things go wrong.
There is no one 'right' way to install Tomcat. Pick the one that works
best for you (and be prepared to try an alternative if you hit problems).
>
> ///Peter
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org