Difference: KnownIssues (51 vs. 52)

Revision 522013-04-03 - LisaZangrando

Line: 1 to 1
 
META TOPICPARENT name="GeneralDocumentation"

Known issues

Line: 9 to 9
 Known problems in CREAM software or in other software modules affecting a CREAM based CE (the list refer to known problem affecting the latest release of the software released in EMI)
Added:
>
>

tomcat5 fails to start unless the supplementary repository is enabled in RHEL 5.9

In RHEL 5.9, installing tomcat5 (tomcat5-5.5.23-0jpp.37.el5) pulls in java-1.7.0-ibm-devel (1:1.7.0.3.0-1jpp.2.el5) IF the supplementary-5 repository is enalbed. However, without the supplementary repo set up, tomcat5 pulls in java-1.4.2-gcj-compat-devel instead. In this case starting tomcat5 fails as seen in /var/log/tomcat5/catalina.out :
Using CATALINA_BASE:   /usr/share/tomcat5
Using CATALINA_HOME:   /usr/share/tomcat5
Using CATALINA_TMPDIR: /usr/share/tomcat5/temp
Using JRE_HOME:
WARNING: error instantiating 'org.apache.juli.ClassLoaderLogManager' referenced by java.util.logging.manager, class not found
java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager not found
   <<No stacktrace available>>
WARNING: error instantiating '1catalina.org.apache.juli.FileHandler,' referenced by handlers, class not found
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler,
   <<No stacktrace available>>
Exception during runtime initialization
java.lang.ExceptionInInitializerError
   <<No stacktrace available>>
Caused by: java.lang.NullPointerException
   <<No stacktrace available>>

Version-Release number of selected component (if applicable): tomcat5-5.5.23-0jpp.37.el5.

How reproducible: always.

Steps to reproduce:

  • install RHEL 5.9
  • install tomcat5
  • service tomcat5 start

Actual results: tomcat5 fails to start normally

Expected results: tomcat5 starts normally

Additional info: Installing java-1.6.0-openjdk-devel allows tomcat5 to start without any error

 

Problem on transferring the sandbox files between the (EMI-3) CREAM CE and the WN on SLURM

This issue doesn't allow the WN to transfer back to the CREAM node the sandbox files and it happens only if the file system is not shared (see the YAIM configuration for SLURM) and CREAM is configured with the following YAIM's variables:

 
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback