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? 

[Matheus Fernandes · Accepted solution]

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.

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.

[Vedran Grudenic]

I am also not sure about the PATH environment variable: I've seen some places mentioning "C:\Program Files\Atlassian\JIRA\jre" for JAVA_HOME, but PATH already contains path to Java bin folders, so I presume it would be a bad idea to have both included. My idea was to use the actual Java installation (not the one bundled with JIRA), but I am just open to anything which would fix this issue.

[Matheus Fernandes]

Create or update the 'JAVA_HOME' environment variable directly, and point it to the Java 8 home: https://confluence.atlassian.com/jira/installing-java-185729673.html#InstallingJava-2.SettingtheJAVA_HOME

[Vedran Grudenic]

Thanks for the reply, but it's not completely clear whether Java 8 home is JDK home, JRE home, or Atlassian bundled JRE home. The image in the link shows a JDK folder, while the text implies JRE. Also, there is the {{JRE_HOME}} variable (IIRC, my JIRA wasn't able to start before I configured that variable too). And, it seems they have no effect on the Java instance Tomcat is pointing to.

[Stephen Cassel]

@Vedran Grudenic you mention that you've got java bin folders on your PATH env. variable. Might be worth while only having a single JDK bin instance in the PATH variable. Make sure that the first JDK bin folder is Java 8

[Vedran Grudenic]

@Stephen Cassel: well I have uninstalled Java 7, but I have several paths in my PATH variable: 1) C:\ProgramData\Oracle\Java\javapath, which contains symlinks to JRE Java executables, then 2) C:\Program Files\Java\jdk1.8.0_60\bin (JDK) and finally 3) C:\Program Files\Java\jre1.8.0_60\bin. Atlassian docs use JDK and JRE terms pretty interchangeably, so I installed JDK knowing that it contains JRE also (and, JIRA comes bundled with JRE, not JDK). Ultimately, I don't think this is an issue anymore, since JIRA seems to be starting after I've changed all variables and registered the service again, but there seem to be some additional issues with plugins (I am checking with Atlassian support and will post my findings when they are done).

[Vedran Grudenic]

Just a follow up, in case someone has the same issue: if you install Bamboo on the same server, it will require full JDK installation to be pointed by JAVA_HOME, so I have JRE_HOME pointing to a JRE folder used by JIRA, and JAVA_HOME pointed to JDK used by Bamboo. That's why I had two env. variables with different folders.

[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.

[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]

Zulu may be a certified java release, but the problem here is that it is NOT supported by Atlassian. That would also explain why their check_java script isn't looking for openJDK when it checks for the java version. Who knows what this actually means when running an Atlassian product. Most of the functionalities will be the same, but there is some proprietary code within the Oracle JDK. If Atlassian is using any of the proprietary code within the applications you will have problems. If they're not, then no worries.

[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!

[Andreas Hofmann]

this is btw a ticket now: 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.

[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]

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

1. 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.
2. 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.
3. 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.  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:

[Eugene Heo]

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

[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>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>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>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]

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

[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.

[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?

[Vedran Grudenic]

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

[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.