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