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
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:
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: