Bug 653885 - Tomcat failed to start properly or the installer ran out of tries.
Summary: Tomcat failed to start properly or the installer ran out of tries.
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Spacewalk
Classification: Community
Component: Installation
Version: 1.2
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space13
TreeView+ depends on / blocked
 
Reported: 2010-11-16 11:31 UTC by Sandro Mathys
Modified: 2010-11-26 15:45 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-26 15:45:38 UTC


Attachments (Terms of Use)
catalina.out (the upgrade was followed by at least one rhn-satellite (re)start already) (14.07 KB, text/plain)
2010-11-16 11:31 UTC, Sandro Mathys
no flags Details

Description Sandro Mathys 2010-11-16 11:31:31 UTC
Created attachment 460812 [details]
catalina.out (the upgrade was followed by at least one rhn-satellite (re)start already)

Description of problem:
Upgrade to spacewalk 1.2 shows worrying message regarding Tomcat.

Version-Release number of selected component (if applicable):
http://koji.spacewalkproject.org/spacewalk/split/spacewalk-5E/server/spacewalk-5E-1.2/x86_64/os

How reproducible:
Only tried once.

Steps to Reproduce:
1. Follow https://fedorahosted.org/spacewalk/wiki/HowToUpgrade
2. Read output of spacewalk-setup --disconnected --upgrade
  
Actual results:
Tomcat failed to start properly or the installer ran out of tries.

Expected results:
no fails/errors :)

Additional info:
tomcat5 seems to start just fine after the upgrade and the catalina.out doesn't seem to show anything problematic (find log file attached). So this might be a bug in spacewalk-setup misinterpreting tomcat's return code.

# spacewalk-setup --disconnected --upgrade
* Setting up Oracle environment.
* Setting up database.
** Database: Setting up database connection for Oracle backend.
DB User? #####
DB Password?
DB SID?  #####
DB hostname?  #####
DB port [1521]?
DB protocol [TCP]?
** Database: Testing database connection.
** Database: Populating database.
** Database: Skipping database population.
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
* Performing initial configuration.
* Activating Spacewalk.
** Certificate not activated.
** Upgrade process requires the certificate to be activated after the schema is upgraded.
* Enabling Monitoring.
* Configuring apache SSL virtual host.
Should setup configure apache's default ssl server for you (saves original ssl.conf) [Y]?
* Configuring tomcat.
** /etc/tomcat5/tomcat5.conf has been backed up to tomcat5.conf-swsave
** /etc/tomcat5/server.xml has been backed up to server.xml-swsave
** /etc/tomcat5/web.xml has been backed up to web.xml-swsave
* Configuring jabberd.
* Creating SSL certificates.
** Skipping SSL certificate generation.
* Deploying configuration files.
* Update configuration in database.
* Setting up Cobbler..
Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services [Y/n]?
cobblerd does not appear to be running/accessible
* Restarting services.
Tomcat failed to start properly or the installer ran out of tries.  Please check /var/log/tomcat*/catalina.out for errors.
* Upgrade flag passed.  Stopping necessary services.
This portion of the Spacewalk upgrade process has successfully completed.

Comment 1 Jan Pazdziora 2010-11-19 16:05:49 UTC
Mass-moving to space13.

Comment 2 Jan Pazdziora 2010-11-20 16:58:26 UTC
(In reply to comment #0)
> Additional info:
> tomcat5 seems to start just fine after the upgrade and the catalina.out doesn't
> seem to show anything problematic (find log file attached). So this might be a
> bug in spacewalk-setup misinterpreting tomcat's return code.

Do you have that upgraded Spacewalk still available?

After the upgrade, was it immediatelly usable?

Are there any error messages in /var/log/httpd/*error_log* from the time of the restart after upgrade?

We actually do not check tomcat's return code because tomcat returns long before all the classes are fully loaded. So we do 20 HEAD requests to the server, 5 seconds apart, to see if it returns success.

Comment 3 Sandro Mathys 2010-11-22 08:08:32 UTC
(In reply to comment #2)
> Do you have that upgraded Spacewalk still available?

yes, it's been updated to 1.2 final now though.

> After the upgrade, was it immediatelly usable?

Not sure whether I tried *immediately* but it was working when I tried and I didn't do anything about it.

> Are there any error messages in /var/log/httpd/*error_log* from the time of the
> restart after upgrade?

No, just the usual stuff:
[Tue Nov 16 12:56:32 2010] [notice] caught SIGTERM, shutting down
[Tue Nov 16 12:56:44 2010] [notice] SELinux policy enabled; httpd running as context user_u:system_r:httpd_t:s0
[Tue Nov 16 12:56:44 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Nov 16 12:56:44 2010] [notice] Digest: generating secret for digest authentication ...
[Tue Nov 16 12:56:44 2010] [notice] Digest: done
[Tue Nov 16 12:56:44 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Tue Nov 16 12:56:44 2010] [notice] Apache configured -- resuming normal operations

> We actually do not check tomcat's return code because tomcat returns long
> before all the classes are fully loaded. So we do 20 HEAD requests to the
> server, 5 seconds apart, to see if it returns success.

Why don't you do both? ;)

Comment 4 Jan Pazdziora 2010-11-22 11:39:33 UTC
(In reply to comment #3)
> > We actually do not check tomcat's return code because tomcat returns long
> > before all the classes are fully loaded. So we do 20 HEAD requests to the
> > server, 5 seconds apart, to see if it returns success.
> 
> Why don't you do both? ;)

Well, I assume it was true (0) in your case anyway so there is not much use.

Comment 5 Jan Pazdziora 2010-11-26 15:45:38 UTC
Let's assume this was a one-off timeout issue.

Closing.

Please reopen if you disagree.


Note You need to log in before you can comment on or make changes to this bug.