Unable to load JetPatch Manager Console till version 4.2.x(also update/upgrade issues)

If JetPatch Manager Console isn't coming up while trying to load it from a browser, here are a few things that might resolve the issue.  

STEP 1: Check Browser

Note:Please make sure you are using either Firefox or Chrome.

If you receive a 404 error in the browser OR if you experience a blank page after login

• Check if disk space is full with df -h.  For example if you see root partition full, you can run the following command to analyze what is taking up the space: du -ah /* | sort -rh | head -n 20
  • Note: the most common issue is the default location of java heap under root is too small and needs to be moved (see article)
  • If /var is the culprit, it is most likely an nginx file under /var/log/nginx/  Thus, you will need to recreate the file that is causing the problem (using localhost.error_log as an example below).  This is also a sign you should upgrade NGINX
    • See instructions how to fix
• If it is not a disk space issue, then restart tomcat several times (4-6 times).
• If there is still an issue, please review the vmanage.log file, because something is preventing the application from starting properly. 
  • Example, if it is something to do with tomcat server.xml, please make sure that file was not recently modified.

If you see other errors or no error at all,

• Run 'java -version' to verify that Java has been upgraded to version 11 and that the default version is set to 11.
• If you noticed performance issues before the page stopped loading and restarting tomcat helps temporarily, then review this performance issue article
• Check for McAfee (or any other Anti Virus) blocking JetPatch. This may happen after performing an upgrade.

STEP 2: Check Service Status

SSH in to your JetPatch application server. 

For each one of the below services, check that they are running in order for JetPatch to run properly.

Example, if you encounter 502 gateway in chrome developer tools it may be one of the following issues:

• nginx issue (restart nginx) or nginx upgrade issue (see below)
• IPV6 is enabled (could be re-enabled after a major or minor OS upgrade (eg: EL 8.6 to 8.8). 
• Java upgrade (make sure you select the right default)
• Check tomcat conf: /usr/share/tomcat/service/tomcat.conf  (is Java version correct there?)

Additional Steps

• NGINX restart
  • Note: If you recently upgraded your Nginx version above 1.21, please make sure you upgraded nginix properly.

  • systemctl restart nginx

    • If Nginx is not loading properly, grant nginx the relevant permissions. This command could be used: 
      • chmod 755 /var/cache/nginx
• Tomcat restart (if you have not already from step 1)

  • systemctl restart tomcat

• PostgreSQL restart (you need to add version number manually)

  • systemctl restart postgresql-<version number>.service  

STEP 3: Proxy check

If all 3 are running and JetPatch is still not accessible, in SSH console run 

curl -kv https://<IP_or_FQDN>/vmanage-server/

If the status code is 200 it is probably related to the proxy configuration. For more information on proxy setup see: JetProxy Overview

If the following actions didn’t resolve the issue and your JetPatch server is still down, please collect manager logs from the server itself , and contact JetPatch support.

STEP 4: Logs

Look at the following logs:

Apache Tomcat Logs (/usr/share/tomcat/default/logs)  
Can be useful in cases of application server failures. In cases of network problems or Java problems:

• vmange.log
• access_tomcat.<date>.log
• catalina.<date>.log
• localhost.<date>.log
• worker.log

Nginx Logs (/var/log/nginx)

Database Logs (typically it is /var/lib/pgsql/<version number>/data/).  If the service is running you can use the following command to get the exact path: 

ps -ef | grep postgres 

Memory and Space issues: Check the output of the following commands:

• free -g
• top -cH

STEP 5: Yum History

Look at yum history, did the server get upgraded since last time it was used successfully?

If using openJDK, the issue may likely be due to the fact that openJDK got updated and therefore the symlink must be updated.  You may first need to unlink.

ln -s /usr/lib/jvm/java-<version-openjdk-version>/jre /usr/java/default

If Using Azure Database for Postgres

Make sure pg_stat is disabled

If it is disabled, logged in the postgres DB and run the following queries

SELECT table _name, column_ name, data_ type FROM information_schema.columns WHERE table_schema='public' AND data_type='oid';

If you see results, just drop the following tables:

• pg_stat_statements
• pg_buffercache

Instructions to truncate NGINX Log File Without Stopping NGINX

This is using localhost.error_log as an example, but feel free to replace with other NGINIX log files

1. Rename the Existing Log File:

    

   mv /var/log/nginx/localhost.error_log 
   /var/log/nginx/localhost.error_log.bak

This command renames the current log file, effectively archiving it.

2. Create a New Log File:

    

   touch /var/log/nginx/localhost.error_log

This initializes a new log file for NGINX to write subsequent logs.

3. Set Appropriate Permissions:

    

   chmod 644 /var/log/nginx/localhost.error_log 
   chown nginx:adm /var/log/nginx/localhost.error_log

Ensure the new log file has the correct permissions and ownership, allowing NGINX to write to it.

4. Instruct NGINX to Reopen Log Files:

    

   nginx -s reopen