Hi,
I am trying to upgrade the Jira to 8.10.0 hosted on AWS EC2 instance. I used the "Installer" Method.
After the successful installation. Jira is unable to restart. When I checked the logs I got the "GC Allocation Failure" message. Can you please assist me?
The log for the error message is as follows.
OpenJDK 64-Bit Server VM (25.202-b08) for linux-amd64 JRE (1.8.0_202-b08), built on Jan 22 2019 13:35:07 by "jenkins" with gcc 4.8.2 20140120 (Red Hat 4.8.2-15) Memory: 4k page, physical 4038204k(418652k free), swap 0k(0k free) CommandLine flags: -XX:+ExplicitGCInvokesConcurrent -XX:GCLogFileSize=20971520 -XX:InitialCodeCacheSize=33554432 -XX:InitialHeapSize=402653184 -XX:MaxHeapSize=2147483648 -XX:NumberOfGCLogFiles=5 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ReservedCodeCacheSize=536870912 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -
Impossible to tell without the full GC Allocation error message (I say full, I just mean the first few lines before it starts giving you line numbers in inscrutable bits of code)
Hi, Thanks for the response. Please see the logs below.
OpenJDK 64-Bit Server VM (25.202-b08) for linux-amd64 JRE (1.8.0_202-b08), built on Jan 22 2019 13:35:07 by "jenkins" with gcc 4.8.2 20140120 (Red Hat 4.8.2-15)
Memory: 4k page, physical 4038204k(418652k free), swap 0k(0k free)
CommandLine flags: -XX:+ExplicitGCInvokesConcurrent -XX:GCLogFileSize=20971520 -XX:InitialCodeCacheSize=33554432 -XX:InitialHeapSize=402653184 -XX:MaxHeapSize=2147483648 -XX:NumberOfGCLogFiles=5 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ReservedCodeCacheSize=536870912 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseGCLogFileRotation -XX:+UseParallelGC.
Is this the required full message?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, that's what you gave us before, which is why I asked for the error message.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Is this what you need? Actually I am new to Linux so I didn't exactly know what will you required to fix the problem.
jira.service
Loaded: loaded (/etc/init.d/jira; generated)
Active: failed (Result: exit-code) since Thu 2020-07-16 21:32:18 UTC; 1min 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 14857 ExecStart=/etc/init.d/jira start (code=exited, status=1/FAILURE)
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: Server startup logs are located in /opt/atlassian/jira/logs/catalina.out
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: Existing PID file found during start.
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: Tomcat appears to still be running with PID 28003. Start aborted.
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: If the following process is not a Tomcat process, remove the PID file and try again:
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: UID PID PPID C STIME TTY TIME CMD
Jul 16 21:32:18 ip-172-31-12-84 jira[14857]: jira 28003 1 1 Jul15 ? 00:22:03 /opt/atlassian/jira/jre//bin/java -Djava.util.logging.config.file=/opt/atla
Jul 16 21:32:18 ip-172-31-12-84 runuser[14874]: pam_unix(runuser:session): session closed for user jira
Jul 16 21:32:18 ip-172-31-12-84 systemd[1]: jira.service: Control process exited, code=exited status=1
Jul 16 21:32:18 ip-172-31-12-84 systemd[1]: jira.service: Failed with result 'exit-code'.
Jul 16 21:32:18 ip-172-31-12-84 systemd[1]: Failed to start jira.service.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, it's not what I asked for, but it is still a very useful thing to see, and something I really would not expect a new Linux or new Jira admin to find so quickly!
This bit is the most important one here:
Existing PID file found during start
A lot of Unix-like systems create PID files when a processes start, and a lot of applications create lock files as well. These files are "flag" files - they announce "something is running", and a lot of things then do a check on them when you try to run them. It is quite common for an application to say "am I already running?", look at one or more of these flag files, and if they find one, they either send a message to the existing process to do something, or they just halt with "I'm running already, so I'm not going to run again"
You have run into the second case - there is a Tomcat (which is the tech underneath Jira) running already, and the new one can't share the resources with the existing one, so it has to shut down.
You will need to shut down all the Tomcat/Jira combinations currently running on the server and start again. I do not know your systems, but I would try a simple reboot to start with (this might start a new Tomcat/Jira process, depending on your config, but it won't do it more than once)
Once you've cleaned out extra processes and have a single Tomcat/Jira process running (even if it ends in a GC error), then you can look for the application log to see why it is failing - this will be in <jira home>/logs/atlassian-jira.log
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Thanks for all your support. I deleted "Catalina.pid" and shutdown and stop all jira/tomcat combination and it worked. Thanks alot.
Regards
Seemi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.