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.  

STEP 1: Check Browser

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

If you receive a 404 error in the browser

• 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 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?)

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

If you recently upgraded your Nginx version above 1.21 and nginx is not starting check in the Nginx conf file path cd /etc/nginx/conf.d/intigua.nginx.conf.

Edit your listen statement from:

listen 443;

to

listen 443 ssl;

and comment out or delete :

# ssl on;   

And restart the 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 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