Monitoring, Management & Location Tracking

VisualRF can encounter an error during startup OR during a root;make OR during an upgrade when it is unable to communicate with the postgresql database. This can be due to custom iptables rules preventing communication over port 5432.

The follow error message may be found in service_watcher log or visualrf.log

2011-06-07 12:57:30,150 ERROR Main com.airwave.svg.init.Startup startup
java.lang.NullPointerException
at com.airwave.core.data.ORProviderImpl.validateSchemas(ORProviderImpl.java:54)
at com.airwave.svg.init.Startup.<init>(Startup.java:213)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.airwave.core.sys.Bootstrapper.main(Bootstrapper.java:83)

This is the error you may see if VisualRF fails during a root; make and/or upgrade

UpdateFS: Skipping 'migrate Apache SSL key/cert to lighttpd'
bin/update_db.pl
(cd /usr/local/airwave/lib/java; JAVA_HOME=/usr/java/jre /bin/su visualrf ./visualrf_schema.sh)
VisualRF startup failed exception follows:
java.lang.NullPointerException
at com.airwave.core.data.ORProviderImpl.validateSchemas(ORProviderImpl.java:54)
at com.airwave.svg.init.Startup.<init>(Startup.java:213)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.airwave.core.sys.Bootstrapper.main(Bootstrapper.java:83)
make[1]: *** [updatedb] Error 1
make[1]: Leaving directory `/root/svn/mercury'
make: *** [upgrade] Error 2


Below is the section from iptables that protects port 5432. Please note that two specific user ids(uid) are allowed access to 5432. UID 0 (root) and UID 101 (visualrf). 

# Postgresql access
-I OUTPUT -m owner -p tcp --dport 5432 --uid-owner 0 -d 127.0.0.1 -j ACCEPT
-I OUTPUT -m owner -p tcp --dport 5432 --uid-owner 101 -d 127.0.0.1 -j ACCEPT
-A OUTPUT -p tcp --dport 5432 -d 127.0.0.1 -j REJECT

IMPORTANT: Visualrf's UID can *VARY* depending on the customers installation method/upgrade path. With the introduction of pound/lighttpd in 7.2.x the UID of visualrf can be either 101 or 102.

The IPTABLES rule MUST match the uid of VisualRF. 

To check the UID of visualRF

#id -u visualrf
101

To check the iptables rules are properly configured for this UID look in /etc/sysconfig/iptables or "grep 5432 /etc/sysconfig/iptables"

[root@kenny etc]# grep 5432 /etc/sysconfig/iptables
-I OUTPUT -m owner -p tcp --dport 5432 --uid-owner 0 -d 127.0.0.1 -j ACCEPT
-I OUTPUT -m owner -p tcp --dport 5432 --uid-owner 101 -d 127.0.0.1 -j ACCEPT
-A OUTPUT -p tcp --dport 5432 -d 127.0.0.1 -j REJECT

If the two entries do not match, you will need to update the uid-owner 101/102 line to match the visualrf uid and restart iptables (service iptables restart).

The following AMP script will rewrite the AMP portion of the iptables file and restart iptables.

/root/svn/mercury/bin/conf_common_post_install

Once communications between visualrf and postgresql are reestablished then startup / upgrade / root;make should succeed.