Unable to load JetPatch Manager Console (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.

Check for McAfee (or any other Anti Virus) blocking JetPatch. This may happen after performing an upgrade.

STEP 1: Check Browser

Please make sure you are using either Firefox or Chrome.

If you receive a 404 error in the browser, 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.

 

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 an nginx issue (restart nignix).  If it's not nginix, then check tomcat conf: /usr/share/tomcat/service/tomcat.conf

1. nginx restart

systemctl restart nginx

• • If Nginx is not loading properly, grant nginx the relevant permissions. This command could be used: 

chmod 755 /var/cache/nginx

2. tomcat

systemctl restart tomcat

3. Postgresql (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 <IP>/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