Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Error Z-JAVA-100

This error message might occur in different flavors:

  1. Z-JAVA-100  Java Virtual Machine cannot be loaded [libjvm.so: cannot open shared object file: No such file or directory] [libjvm.so]
    1. The reason for this problem is that JobScheduler cannot find a Java Virtual Machine (libjvm.so). This example is for Unix but could occur for Windows accordingly, see How will JobScheduler determine the location of the JVM for Windows?
    2. The JVM might have been available during set-up for the users that did perform the installation (e.g. by /etc/profile, /etc/bashrc, $HOME/.bash_profile etc. However, JobScheduler does not log in with a shell and therefore no profile is executed. Instead the JVM usually is found by JobScheduler via the $JAVA_HOME variable. If not otherwise specified then you could try to set this variable before JobScheduler starts, e.g. by adding the location of your JVM to this variable in the script $SCHEDULER_HOME/bin/jobscheduler_environment_variables.sh | .cmd
    3. For Unix please check the usage of the LD_LIBRARY_PATH environment variable in that script. This variable points to the directory where the JVM library libjvm.so (from the above error message) is located. If not correct then add the respective path to LD_LIBRARY_PATH.
    4. You could take JobScheduler error messages seriously: the fact that libjvm.so cannot be found is some glitch about paths or permissions. It is not about a JVM that wouldn’t work, it’s about a JVM that cannot be found.
  2. Z-JAVA-100  Java Virtual Machine cannot be loaded [libjvm.so: wrong ELF class: ELFCLASS64] [libjvm.so]
    1. The reason for this problem might be that you downloaded a JobScheduler 32-bit release and installed it in a 64-bit JVM environment.
    2. In fact you can run a 32-bit JobScheduler in 64-bit environment, however, this would require a 32-bit JVM to be used in that environment. There are rare cases when this set-up makes sense, e.g. due to different memory management of the JVM for 32-bit and 64-bit.

See also