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:
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
We were able to reproduce the problem internally with Spacewalk nightly. Tomáš, could you investigate more?
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.
It seem that the fedora package cannot find appropriate logger ... java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
I created: Bug 735460 - java.lang.ClassNotFoundException: com.mchange.v2.log.MLog for c3p0 fedora 15 component.
(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?
(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
(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.
nice work people :). To test do I just have to enable the nightly builds as per * https://fedorahosted.org/spacewalk/wiki/HowToInstall
(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.
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??
(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.
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
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.)
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 :)
(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?
Yes, it's safe. And also much better than to link different jars for every OS. spacewalk.git: 2f93f6226b9634c1b1b34c86bef6ece21e342e8e
*** Bug 742576 has been marked as a duplicate of this bug. ***
Spacewalk 1.6 has been released.