Bug 653885

Summary: Tomcat failed to start properly or the installer ran out of tries.
Product: [Community] Spacewalk Reporter: Sandro Mathys <sandro>
Component: InstallationAssignee: Jan Pazdziora <jpazdziora>
Status: CLOSED CANTFIX QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: low Docs Contact:
Priority: low    
Version: 1.2   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-26 15:45:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 653453    
Attachments:
Description Flags
catalina.out (the upgrade was followed by at least one rhn-satellite (re)start already) none

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.