Jira Data Center fails to start after upgrade to 10.3 due to SIGSEGV
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Jira Data Center 10.3.16+ fails to start with a SIGSEGV error in libapr-1.so.0. Learn how to switch to the NIO connector or update libraries.
Diagnosis
Take a close look at the hs_err pid file that gets generated while Jira node crashes. The crash happens outside the Java Virtual Machine in native code
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f3984f322e0, pid=2737768, tid=2737769
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.18+8 (17.0.18+8) (build 17.0.18+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.18+8 (17.0.18+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libapr-1.so.0+0x212e0] apr_pool_create_ex+0xf0Cause
Jira Data Center v10.3.16 and later versions include updated bundled components, including OpenJDK 17.0.18 and newer Tomcat Native libraries. Version mismatch between the newly bundled Tomcat Native libraries in Jira 10.3.16 and the APR (Apache Portable Runtime) library on the host OS causes a segmentation fault (SIGSEGV) during the initialization of the SSL stack. The crash typically occurs in the libapr-1.so.0 native library.
Solution
To resolve the startup failure, you should switch from the APR connector to the standard Java NIO connector. Modern Java versions provided with Jira 10 offer comparable performance to APR without the risk of native library conflicts.
Option 1
Stop the Jira application.
Navigate to your Jira installation directory and open the conf/server.xml file for editing.
Locate the <Connector> tag responsible for your connection (typically the SSL/HTTPS connector).
Identify the protocol attribute. If it is set to org.apache.coyote.http11.Http11AprProtocol, change it to org.apache.coyote.http11.Http11NioProtocol.
Locate the AprLifecycleListener (usually near the top of the file) and comment it out:
<!-- <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> -->Ensure the <Connector> tag is properly closed with a > bracket.
Save the file and start Jira.
Option 2
If you prefer to continue using the APR connector, you must ensure the host operating system libraries are compatible with the newer OpenJDK version bundled with Jira.
Work with your Linux administrator to update the APR library on the host. For example, on RHEL/Oracle Linux, run:
sudo yum update aprIf updates are not available or do not resolve the crash, you may need to uninstall the apr package from the host OS entirely to force Jira to use the standard Java connectors.
Option 3
You can force Jira to ignore the native APR library by adding this to your JVM startup arguments:
-Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true. Please refer the kb for Setting properties and options on startup | Administering Jira applications Data Center 11.3 | Atlassian Documentation
External documentation for Reference: The Apache Tomcat Native Library 2.0 - Documentation Index
Was this helpful?