Skip to main content

How to troubleshoot when Nexus Repository suddenly crashed or is not responding?

Updated

If your Nexus instance suddenly crashes or not responding, the following troubleshooting steps are recommended to help diagnostic the root cause:

  1. Collect Diagnostics Before Restarting
    Before restarting the Nexus service, collect thread dumps and system diagnostics. This helps in identifying what the process was doing at the time of the crash. Use the following script to collect thread dumps, process info, and network connections for analysis. (Adjust the working directory as needed) 
     
    workingDirectory="/path/to/nexus-data"; 
filePath="${workingDirectory%/}/log/tasks/script-$(date +"%Y%m%d%H%M%S")000.log"; 
(for i in {1..5};do top -H -b -n1 | head -n60;kill -3 $(ps auxwww | grep -F 'org.sonatype.nexus.karaf.NexusMain' | grep -vw grep | awk '{print $2}' | tail -n1); netstat -topen 2>/dev/null || cat /proc/net/tcp* 2>/dev/null;sleep 2;done;sed -n -E "/^[[:space:]]*$(date +'%Y-%m-%d %H')/,\$p" ${workingDirectory}/log/jvm.log) >> ${filePath};echo "Saved $(grep -c -i 'Full thread dump' ${filePath}) dumps into: ${filePath}";
     
  2. Review Nexus
    Examine nexus.log and request.log for errors or warnings around the time of the crash. Look for abrupt stops, out-of-memory errors, or network issues. 
     
  3. Check JVM and Memory Settings
    Ensure that JVM heap and direct memory settings are appropriate for your server's available resources. Over-allocating memory to the JVM can starve the OS and lead to crashes. 
     
  4. Check System Logs and Resources
    - Review systemctl logs for any errors or warnings event around the time of the crash.
    - Review CPU and memory usage on the server. Insufficient memory or CPU can cause the JVM to be killed by the OS (e.g., by the Linux OOM killer). Thus can be verified by checking /var/log/messages for entries like "killed process" to confirm if the OS terminated the process due to resource exhaustion. 
    - Consider increasing RAM and CPU if resources are low. 
     
  5. Monitor and Gather Telemetry
    If possible, collect 24 hours of telemetry (memory, IO, network, etc.) prior to the incident to help identify trends or resource exhaustion.
     
  6. Check for External Factors
    If Nexus is behind a load balancer or reverse proxy, check those logs for connection issues. Also, verify network stability and database connectivity if using an external database. 
     

If you follow these steps, you will maximize the chances of identifying the root cause of a sudden Nexus crash. If the issue persists or you need additional help on the RCA, provide all collected data to Sonatype support includes a full support zip (without file limits) for further assistance.

Related articles