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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
