Bug 732350 - 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 CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Installation
Version: 1.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
: 742576 (view as bug list)
Depends On: 735460
Blocks: space16
TreeView+ depends on / blocked
 
Reported: 2011-08-22 06:02 UTC by Phil
Modified: 2011-12-22 16:49 UTC (History)
3 users (show)

Fixed In Version: spacewalk-java-1.6.39-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-22 16:49:41 UTC


Attachments (Terms of Use)
catalina.out (7.96 KB, text/plain)
2011-08-22 06:02 UTC, Phil
no flags Details
rhn_taskomatic_daemon.log (3.28 KB, text/plain)
2011-09-07 06:28 UTC, Phil
no flags Details
patch for rhn_taskomatic_daemon.conf (527 bytes, patch)
2011-09-16 00:07 UTC, Phil
no flags Details | Diff

Description Phil 2011-08-22 06:02:12 UTC
Created attachment 519223 [details]
catalina.out

Description of problem:
I have installed F15x64 as a VM and, as per the doco on https://fedorahosted.org/spacewalk/wiki/HowToInstall, completely updated my system prior to installation.  At the end of spacewalk-setup --disconnected I get the error of:

* Restarting services.
Tomcat failed to start properly or the installer ran out of tries.  Please check /var/log/tomcat*/catalina.out for errors.
Installation complete.


Version-Release number of selected component (if applicable):
1.5

How reproducible:
I have done 2 separate installations, one with postgres and the other with oracle.

Steps to Reproduce:
1. Follow the steps on https://fedorahosted.org/spacewalk/wiki/HowToInstall
  
Actual results:
broken installation

Expected results:
working installation

Additional info:

Comment 1 Phil 2011-08-22 06:04:41 UTC
When navigating to my server I get redirected to /rhn/Login.do but am greeted with a 404 saying:

HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/6.0.32

Comment 2 Jan Pazdziora 2011-09-02 12:24:39 UTC
We were able to reproduce the problem internally with Spacewalk nightly.

Tomáš, could you investigate more?

Comment 3 Tomas Lestach 2011-09-02 15:51:47 UTC
Yes, the trouble is c3p0 that is available now in F15 repo in a higher version that the package we'd like to use from jpackage repo.

The quickest workaround is to step back f.e.
# yum downgrade c3p0 -y
to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.

Comment 4 Tomas Lestach 2011-09-02 17:38:34 UTC
It seem that the fedora package cannot find appropriate logger ...
java.lang.ClassNotFoundException: com.mchange.v2.log.MLog

Comment 5 Tomas Lestach 2011-09-02 17:42:35 UTC
I created:
Bug 735460 - java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
for c3p0 fedora 15 component.

Comment 6 Jan Pazdziora 2011-09-05 07:24:47 UTC
(In reply to comment #3)
> Yes, the trouble is c3p0 that is available now in F15 repo in a higher version
> that the package we'd like to use from jpackage repo.
> 
> The quickest workaround is to step back f.e.
> # yum downgrade c3p0 -y
> to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.

Can we just require (in rpm dependencies) the exact c3p0 version on Fedora 15 for now?

Comment 7 Jan Pazdziora 2011-09-05 09:50:16 UTC
(In reply to comment #6)
> (In reply to comment #3)
> > Yes, the trouble is c3p0 that is available now in F15 repo in a higher version
> > that the package we'd like to use from jpackage repo.
> > 
> > The quickest workaround is to step back f.e.
> > # yum downgrade c3p0 -y
> > to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.
> 
> Can we just require (in rpm dependencies) the exact c3p0 version on Fedora 15
> for now?

Actually, mchange-commons is already installed on my Fedora 15, so the trick is to do

# ln -s /usr/share/java/mchange-commons.jar /var/lib/tomcat6/webapps/rhn/WEB-INF/lib

Comment 8 Jan Pazdziora 2011-09-05 11:18:29 UTC
(In reply to comment #7)
> 
> Actually, mchange-commons is already installed on my Fedora 15, so the trick is
> to do
> 
> # ln -s /usr/share/java/mchange-commons.jar
> /var/lib/tomcat6/webapps/rhn/WEB-INF/lib

And this is what I did for Fedora 15 in Spacewalk master, 5024fea0db061d82a0ba61d6b80c7843c34678b4.

Tagged as spacewalk-java-1.6.39-1.

Comment 9 Phil 2011-09-05 23:00:38 UTC
nice work people :).  To test do I just have to enable the nightly builds as per

* https://fedorahosted.org/spacewalk/wiki/HowToInstall

Comment 10 Jan Pazdziora 2011-09-06 06:28:24 UTC
(In reply to comment #9)
> nice work people :).  To test do I just have to enable the nightly builds as
> per
> 
> * https://fedorahosted.org/spacewalk/wiki/HowToInstall

Well, if you don't want to pollute your released installation with nightly bits, just do

# ln -s /usr/share/java/mchange-commons.jar /var/lib/tomcat6/webapps/rhn/WEB-INF/lib/mchange-commons.jar
# service tomcat6 restart

-- that should do the trick.

Comment 11 Phil 2011-09-07 02:56:46 UTC
excellent.  well, i can confirm that after doing the symlink everything now works on a fresh install; including a dependency issue I used to have with tanukiwrapper which is no doubt unrelated here..

is this where I change the status of this bug to CLOSED??

Comment 12 Jan Pazdziora 2011-09-07 06:13:54 UTC
(In reply to comment #11)
> excellent.  well, i can confirm that after doing the symlink everything now
> works on a fresh install; including a dependency issue I used to have with
> tanukiwrapper which is no doubt unrelated here..
> 
> is this where I change the status of this bug to CLOSED??

We will close this bugzilla once the fix is in released Spacewalk -- so far we only have it in nightly builds (and we have this manual workaround). Please leave it open, we will take care of it later.

Comment 13 Phil 2011-09-07 06:28:42 UTC
Created attachment 521801 [details]
rhn_taskomatic_daemon.log

hmmm, well even though the installation seemed to work and I have been able to create a new channel with 3 repositories bound to it there is an issue related to the scheduler where according to spacewalk "The scheduling service appears down. Please contact your Satellite administrator.".

[root@spacewalk ~]# service taskomatic status
RHN Taskomatic is running (6632).

[root@spacewalk ~]# netstat -pant|grep task
tcp   0  0 127.0.0.1:32001  127.0.0.1:31003   ESTABLISHED 6632/taskomaticd

From looking at taskomatic's log output I noticed that it referenced "mchange", being the library I manually linked before.


For this new installation I did a dvd installation, updated, installed spacewalk as per the fedorahosted guide on to postgres and then went through the creation of channels and repos.

should I file a separate bug and if so what extra information would be required?

thanks again for your assistance

Comment 14 Tomas Lestach 2011-09-15 08:10:16 UTC
Yes, we need to add the /usr/share/java/mchange-commons.jar to taskomatic wrapper.java.classpath as well (in /etc/rhn/default/rhn_taskomatic_daemon.conf).

(I'll fix and test the change as soon as I get my F15 machine running.)

Comment 15 Phil 2011-09-16 00:07:46 UTC
Created attachment 523466 [details]
patch for rhn_taskomatic_daemon.conf

I can confirm that including the mchange jar fixes taskomatic.  All i did was modify the conf file and restarted taskomatic.  within seconds it started working through its schedule and now all is good.

Thanks again everyone for your assistance :)

Comment 16 Jan Pazdziora 2011-09-16 06:58:16 UTC
(In reply to comment #15)
> Created attachment 523466 [details]
> patch for rhn_taskomatic_daemon.conf
> 
> I can confirm that including the mchange jar fixes taskomatic.  All i did was
> modify the conf file and restarted taskomatic.  within seconds it started
> working through its schedule and now all is good.
> 
> Thanks again everyone for your assistance :)

Tomáš, is it OKay / harmless to have this patch applied even on OSes where the thing does not exist as a separate .jar?

Comment 17 Tomas Lestach 2011-09-16 09:35:15 UTC
Yes, it's safe. And also much better than to link different jars for every OS.

spacewalk.git: 2f93f6226b9634c1b1b34c86bef6ece21e342e8e

Comment 18 Jan Pazdziora 2011-10-02 12:25:55 UTC
*** Bug 742576 has been marked as a duplicate of this bug. ***

Comment 19 Milan Zázrivec 2011-12-22 16:49:41 UTC
Spacewalk 1.6 has been released.


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