nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA not starting after upgrade to 7.0

Vedran Grudenic

I just tried migrating from 6.2.5 to JIRA 7.0 (JIRA Software) following the Rapid Upgrade Method for our local Windows server (Windows Server 2012 R2 64-bit). We had JIRA + JIRA Agile installed, with several plugins.

The installer finished with no errors, but JIRA is no longer working. The service appears to be running (I can stop it and start it), and the Event viewer contains no logs. When I try to open the page inside a browser, it just closes the socket with no response.

Checking the logs directory revealed a bunch of errors during startup:

The stdout log (jira200214103609-stdout.2015-10-13.log) shows that the service cannot instantiate practically any class, saying that major.minor version is unsupported:

2015-10-13 13:21:03 Commons Daemon procrun stdout initialized

2015-10-13 13:21:15,642 localhost-startStop-1 ERROR      [o.a.c.c.C.[Catalina].[localhost].[/]] Error configuring application listener of class com.atlassian.jira.web.ServletContextProviderListener
java.lang.UnsupportedClassVersionError: com/atlassian/jira/web/ServletContextProviderListener : Unsupported major.minor version 52.0 (unable to load class com.atlassian.jira.web.ServletContextProviderListener)
	at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2476)
	at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:854)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1274)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1157)
	at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:520)
	... 7 filtered
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

The stderr log (jira200214103609-stderr.2015-10-13.log) shows many errors failing to instantiate log4j appenders:

log4j:ERROR Could not instantiate class [com.atlassian.jira.logging.JiraHomeAppender].

Is there a step I missed during the installation?

Accepted answers

Matheus Fernandes

Vedran,

Yes, that is correct. JIRA 7 needs Java 1.8 in order to run as per the JIRA Server 7.0 Supported platforms docs. smile

Please install the latest version of Java, update the JAVA_HOME to 1.8 and try to start JIRA again.

All comments

Vedran Grudenic

Also, not sure if this makes sense, but when I run {{check-java.bat}} inside {{Atlassian\JIRA\bin}} it returns "Wrong JVM version! JIRA requires at least 1.8 to run". Is this correct? I have been running 1.7 for JIRA 6.2.5, and I don't see this being documented anywhere.

Matheus Fernandes

Vedran,

Yes, that is correct. JIRA 7 needs Java 1.8 in order to run as per the JIRA Server 7.0 Supported platforms docs. smile

Please install the latest version of Java, update the JAVA_HOME to 1.8 and try to start JIRA again.

Vedran Grudenic

Oh crap, I can't believe I missed that (even after searching again). Thanks a lot, it's being installed.

Matheus Fernandes

Sure thing! Let us know if you're able to start JIRA afterwards.

Vedran Grudenic

One detail though, there are different claims in the docs, so I would just like to confirm: JAVA_HOME should point to the JDK folder, and JRE_HOME should point to JRE? Or should they both point to JRE? I think I tried every possible combination but it still isn't working.

Ravi Ledwani

I am still unable to connect with JIRA. I am getting a JIRA Startup Failed error (Error occurred while starting component 'com.atlassian.jira.service.DefaultServiceManager'. caused by: Error creating GenericValue (SQL Exception while getting value: (Invalid column type: getBLOB not implemented for class oracle.jdbc.driver.T4CLongRawAccessor))) on the browser and the address of the URL states localhost:/JIRALockedError.

Did anyone see this error? What are steps to resolve this?

Coskun Sunali

I am having the same issue after upgrading to JIRA 7.

The "JAVA_HOME" system variable has value of

C:\Program Files (x86)\Atlassian\JIRA\jre

Removed service using:

C:\PROGRA~2\ATLASS~1\JIRA\bin&gt;service.bat remove
Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
Service will use the bundled JRE.
Failing that, service will try to guess them from the registry.
Removing the service 'JIRA120415233250' ...
Using CATALINA_BASE:    "C:\Program Files (x86)\Atlassian\JIRA"
The service 'JIRA120415233250' has been removed

Reinstalled service using (please see the double back-slashes with the JRE and JVM paths):

C:\PROGRA~2\ATLASS~1\JIRA\bin&gt;service.bat install
Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
Service will use the bundled JRE.
Failing that, service will try to guess them from the registry.
Installing the service 'JIRA120415233250' ...
Using CATALINA_HOME:    "C:\Program Files (x86)\Atlassian\JIRA"
Using CATALINA_BASE:    "C:\Program Files (x86)\Atlassian\JIRA"
Ignoring JAVA_HOME:        "C:\Program Files (x86)\Atlassian\JIRA\jre\"
Using JRE_HOME:         "C:\PROGRA~2\ATLASS~1\JIRA\bin\\..\jre"
Using JVM:              "C:\PROGRA~2\ATLASS~1\JIRA\bin\\..\jre\bin\server\jvm.dll"
The service 'JIRA120415233250' has been installed.

Check-java.bat returns:

C:\PROGRA~2\ATLASS~1\JIRA\bin&gt;check-java.bat
*******************************************************************************
*******      Wrong JVM version! JIRA requires at least 1.8 to run.      *******
*******************************************************************************

I get the following errors whenever I try to start the service:

[2015-10-14 04:07:52] [info]  [597904] Commons Daemon procrun (1.0.15.0 64-bit) started
[2015-10-14 04:07:52] [info]  [597904] Running 'JIRA120415233250' Service...
[2015-10-14 04:07:52] [info]  [211984] Starting service...
[2015-10-14 04:07:52] [error] [211984] %1 is not a valid Win32 application.
[2015-10-14 04:07:52] [error] [211984] Failed creating java C:\PROGRA~2\ATLASS~1\JIRA\bin\\..\jre\bin\server\jvm.dll
[2015-10-14 04:07:52] [error] [211984] %1 is not a valid Win32 application.
[2015-10-14 04:07:52] [error] [211984] ServiceStart returned 1
[2015-10-14 04:07:52] [error] [211984] %1 is not a valid Win32 application.
[2015-10-14 04:07:52] [info]  [597904] Run service finished.
[2015-10-14 04:07:52] [info]  [597904] Commons Daemon procrun finished

If I paste the following path into "Start > Run", it fails:

C:\PROGRA~2\ATLASS~1\JIRA\bin\\..\jre\bin\server\

Windows cannot find 'C:\PROGRA~2\ATLASS~1\JIRA\bin\\..\jre\bin\server\'. Make sure you typed the name correctly, and then try again.

If I remove one of the back-slashes, it works:

C:\Program Files (x86)\Atlassian\JIRA\jre\bin\server

So, my JIRA instance is completely out of service at the moment and I have employees who need to use the system asap.

What do we do?

Some info: It is a x64 Windows but we run JIRA x32 version. That has never been a problem before with JIRA 6.x.x. We use the bundled JRE and we don't have a separate installation for JRE or JDK.

Andrew Robertson_o1hy2r

I'm experiencing the same issue even though the JAVA_HOME variable is set

Vedran Grudenic

A couple of clarifications which may be of help everyone here:

Most places on Atlassian suggest that JAVA_HOME should contain no spaces, i.e. use shortened 8.1 path format. This means you should have something similar to C:\Progra~1\Atlassian\JIRA\jre, not the full "Program Files" path. Note also it's Progra~2 if you have JIRA installed inside Program Files (x86) on a 64-bit machine.
check-jira.bat is not mean to be executed directly, so just ignore what it says. It doesn't use JAVA_HOME directly, but instead a temporary variable _EXECJAVA which is set by other scripts (which in turn call check-jira.bat). For example, config.bat first checks if JRE_HOME is set, then if JAVA_HOME is set, and then calls check-jira.bat to check the version. So, if these two don't point to the same Java instance, the whole check won't make much sense - my guess is some parts of JIRA use the former, and some the latter. Tldr; if you start check-jira.bat from the command prompt, it will always say you don't have the correct version, because it won't find any version.
If JIRA is run as a service, then there is also Tomcat's path to Java JVM, which is completely independent from these environment variables. If you start Tomcat's config (like explained here), you may notice that the Java tab might still be pointing to a different Java installation (mine was, at least). My suggestion is to set that value to the same Java instance path pointed by both JAVA_HOME and JRE_HOME. The path should be to the jvm.dll in your Java's jre\bin\server subfolder.

Update: Ok, this last part (Tomcat's path) is fixed if you run service remove, followed by service install, as the script will configure Tomcat correctly after that. Just make sure your Java paths do not contain spaces. I recommend doing this to make sure everything is done correctly.

All that being said, my JIRA is still offline. smile I am presuming it's a plugin issue at this moment, so I will try to fiddle with the logs a bit more.

My current config settings are shown below:

Vedran Grudenic

Make sure your {{JAVA_HOME}} contains no spaces, i.e. it should be set to {{C:\Progra~2\Atlassian\JIRA\jre}} in your case (since you're using `Program Files (x86)`. Set the {{JRE_HOME}} to the same location too, and then run {{service remove}} / {{service install}} to make sure Tomcat picks up these changes.

Vedran Grudenic

You can see that the script actually has a bug; if it cannot find {{JAVA_HOME}}, then it uses the current folder (the one where service.bat is located), and tries to go backwards one folder (hence the \..\), but current folder already has a backslash at the end (and most likely not all components in JIRA can handle a path like this). My opinion is that service.bat should just fail immediately if there is not {{JAVA_HOME}} present, not try to guess paths, because it helps no one.

Vedran Grudenic

After fixing all Java paths, all that was left to do before starting JIRA was to remove old incompatible plugins, as explained here. Atlassian support pointed me to this after I sent them my log files.

Btw, I updated Bamboo also, and it's now also not working. But, there was an interesting issue while reinstalling Bamboo service: it complained that JAVA_HOME has to point to the JDK installation, not JRE.

So the correct configuration for JIRA + Bamboo installations seems to be:

JAVA_HOME: path to Java JDK (v8 for JIRA 7.0)
JRE_HOME: path to Java JRE (also v8)

Vedran Grudenic

You can try removing all installed plugins (except jira-software-*) into a different folder and restarting Jira.

Andreas Hofmann

I have a similar problem:

We're running JIRA on a Linux Debian Server with Java 8 installed:

jira1:/opt# java -version
openjdk version "1.8.0_66"
OpenJDK Runtime Environment (Zulu 8.11.0.1-linux64) (build 1.8.0_66-b17)
OpenJDK 64-Bit Server VM (Zulu 8.11.0.1-linux64) (build 25.66-b17, mixed mode)

Also JAVA_HOME is set:

jira1:/opt# echo $JAVA_HOME
/usr/lib/jvm/zulu-8-amd64/jre

Still, when I try to launch JIRA with this command:

/opt/jira-inst/bin/start-jira.sh

It's saying

Server startup logs are located in /opt/jira-inst/logs/catalina.out
Using CATALINA_BASE:   /opt/jira-inst
Using CATALINA_HOME:   /opt/jira-inst
Using CATALINA_TMPDIR: /opt/jira-inst/temp
Using JRE_HOME:        /usr/lib/jvm/zulu-8-amd64/jre
Using CLASSPATH:       /opt/jira-inst/bin/bootstrap.jar:/opt/jira-inst/bin/tomcat-juli.jar
Using CATALINA_PID:    /opt/jira-inst/work/catalina.pid
*************************************************************************************************************************************
**********     Wrong JVM version! You are running with .. but JIRA requires at least 1.8 to run.      **********
*************************************************************************************************************************************

It seems that it cannot detect the java version at all: "You are running with ..". Somebody ever had a similar problem or an idea how to fix this?

Just a side note: I was able to start JIRA 6.4.11 absolutely fine with this java version. We're also using the same java version for our Confluence installation (currently at v5.8.9) which runs perfectly fine, too!

Thanks and greetings,

Andy!

anbu thiru

use oracle jdk-8 which is supported

anbures

Andreas Hofmann

This can't be the solution: Zulu is a certified java release and also works perfectly with JIRA 6.4 and Confluence 5.8. The problem is, that JIRA 7 does not detect the version number correctly.

Andreas Hofmann

this is btw a ticket now: https://jira.atlassian.com/browse/JRA-46152

mwraky

Sorry for late response. Hope this still helps. On Unix inside the bin folder there is a check-java.sh i'm sure there is the same for windows must be a .bat or similar. Anyway, it's terrible. It doesn't pick up things like OpenJDK etc. So to fix this edit the bin/catalina.sh or bin/catalina.bat (for windows i think) and just comment out the lines where it attempts to 'check_java'. Then run the startup script again and you'll be good to go Hope this helps someone else.

Andreas Hofmann

@Raky Pathak I also added a fix here: https://jira.atlassian.com/browse/JRA-46152

Chris Solgat

One of the things that we do to ensure that the correct paths are being used is this: First, make sure that the dedicated user account that will run JIRA has the JAVA_HOME environment variable set to your java installation, and then make sure that the PATH variable includes the java path as well. The second thing we do is add these two lines to the beginning of the catalina.sh script: JAVA_HOME=/your/path/to/jdk8 JRE_HOME=$JAVA_HOME/jre Setting the environment variable for the dedicated user will allow you to call the startup scripts. If your user doesn't have the variable set and it's not set globally, you will get an error when trying to execute the scripts. By "re-setting" the environment variable inside of catalina.sh, you are forcing the application to start with that specific version of java, which comes in very handy if you are in an environment that doesn't allow you to modify any of the Environment Variables.

Eugene Heo

using "C:\Progra~1\" solved my issue after a couple hours of troubleshooting.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

migration

jira-software

error