IMPORTANT:
Issues Pertaining to Installation
Issues Related to Starting WEM
Problem:
|
WEM server doesn't
start.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Postgres doesn't start.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Received the following
error message in postgres log:
“2008-09-13
15:57:31 IST bsdb ERROR: column "data_touseravg_bps"
does not exist at character 4332008-09-13 15:57:31 IST bsdb STATEMENT:
SELECT "sampledate", "sampletime", "vpnname", "vpnid", "apn", "acc_req_sent",
... FROM apn_current WHERE ("boxername"='bngnc22')
AND ( ( ("sampledate"='2008-09-13') AND ("sampletime">='33900')
) ... ORDER BY "sampledate", "sampletime", "vpnname", ...; ”
|
Possible Cause(s): |
The mentioned table
in error logs may not be in sync with the old table.
There are two tables
for each bulkstat subsystem in database: old and current (for example,
card and card_current, port and port_current,
etc.).
|
Action(s): |
There is one workaround
for this but there will be data loss for that mentioned counter.
Manually drop the column from table to make the tables in sync.
There is data loss only for that particular column. After this,
restart all the bulkstat processes (bulkstatparser and bulkstatserver).
After restarting, bulkstatparser will
re-add that column in both the tables and data will be populated
for that column.
|
Problem:
|
Received the following
error message in postgres log:
“ERROR: trigger
"xxxxxxxxxxxxxxxxxxxx" for table "yyyyyyyyyyyyy" does not exist
ERROR: function ffffffffffffffffffff()
does not exist
ERROR: view "vvvvvvvvvvvvvvvvvvvvv"
does not exist”
|
Possible Cause(s): |
Error messages regarding
function, trigger and view are logged in logfile when the DROP statement
is executed while initializing the EMS databases. SQL file used
for initializing the database contains a sequence of DROP and CREATE
statements for every function, trigger and view. These messages
do not have any impact on postgres as well as WEM functionality.
|
Action(s): |
No action required.
This is a normal behavior.
|
Issues Related to Login
Problem:
|
Could not login to
WEM.
|
Possible Cause(s): |
Invalid user name or
password.
|
Action(s): |
Verify that the username
and password you are entering is correct.
|
Problem:
|
Received “Could not
connect to server, destroying applet” message.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Received “Java policy
file is outdated or missing” message.
|
Possible Cause(s): |
The .java.policy file is
either missing from the user’s home directory on the client
machine or it has expired.
|
Action(s): |
|
Problem:
|
Received “Server could
not establish connection with client, therefore notifications will
not work.” message.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Superuser (any user)
account locked.
|
Possible Cause(s): |
The configured number
of consecutive failed logins has been reached.
|
Action(s): |
Check the configuration
of the no limit ConsecutiveFailLogin parameter in the ua.cfg file
(located in the <ems_dir>/server/etc directory
by default). If users are frequently locked out due to reaching
the maximum limit, you may consider increasing the limit, or disabling
the functionality. You may also consider reducing the amount of
time the account is locked out by modifying the configuration of
the no locked out LockOutInterval parameter
also contained in the ua.cfg file.
|
Issues Related to the Web Browser
Problem:
|
WEM Client cannot be
started.
|
Possible Cause(s): |
Unsupported JRE is installed
on the client machine.
|
Action(s): |
As of 14.0.2266, the
only supported JRE is either JRE 1.5 or 1.6.
|
Problem:
|
Unable to invoke Online
Help
|
Possible Cause(s):
|
The browser is configured
to block pop-ups.
|
Action(s):
|
Configure your browser
to allow pop-ups from the WEM server.
|
Problem:
|
WEM Client-Server version
mismatch message is received.
|
Possible Cause(s): |
Attempting to login
into an older version of the WEM after having logged into a newer
version of the application.
|
Action(s): |
This is caused by the
browser storing the.jar files
for the newer version of the WEM client in its cache.
|
Problem:
|
After WEM upgrade or
installation of a new version, various screens do not open.
|
Possible Cause(s): | Check the java console and if you get exceptions like "Exception in thread "AWT-EventQueue-2" java.lang.NoClassDefFoundError", it could be the case that the browser cache is enabled on your workstation and needs cleanup. |
Action(s): | Clean up the temporary internet cache from your browser and re-invoke the WEM Client. |
Issues Pertaining to CORBA Communication
Problem:
|
IMG is unmanageable.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Received “Callbacks
between server and client are not working. Screen cannot be invoked.” message.
|
Possible Cause(s): |
|
Action(s): |
|
Issues Related to Bulk Statistics
Issues Pertaining to Configuration Backup
Problem:
|
Configuration files
are not getting backed up.
|
Possible Cause(s): |
|
Action(s): |
|
Issues Pertaining to Alarms
Problem:
|
The WEM is not receiving
alarms.
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Not able to receive
Mail Notifications
|
Possible Cause(s): |
|
Action(s): |
|
Problem:
|
Script execution on
receiving ALARM fails
|
Possible Cause(s): |
|
Action(s): |
|
Issues Pertaining to the Process Monitor (PSMON)
Problem:
|
WEM processes are not
restarted after a crash.
|
Possible Cause(s): |
|
Action(s): |
|
Issues Pertaining to Starting and Stopping EMS Processes
Issues Pertaining to Java
Problem:
|
The following message
is displayed when attempting to access WEM dialogs containing tables
after changing the look and feel option to Windows: “java.lang.NullPointerException”.
|
Possible Cause(s): |
This may be an issue
related to JRE 1.4.x.
|
Action(s): |
If JRE 1.4.x is currently
installed, uninstall it and then install JRE 1.5 or 1.6.
|
Problem
|
The WEM client hangs
when the user tries to load the configuration from the client file
system. This is typical with older WEM builds
|
Possible Cause(s) |
There is a bug in
JRE 1.6.0_24 and above where JFileChooser class checks
for the “modifyThreadGroup" permission which may not exist
in the current .java.policy file.
|
Action(s) |
Update the.java.policy file
on any client machine that uses JRE 1.6.0_24 and above
with the following line:
permission java.lang.RuntimePermission “modifyThreadGroup."
|
Problem
|
An error message displays
to update the.java.policy file
when the user invokes the WEM url. This is typical with newer WEM
builds.
|
Possible Cause(s) |
There is a bug in
JRE 1.6.0_24 and above, where JFileChooser class checks
for the “modifyThreadGroup" permission, which may not exist
in the current .java.policy file.
|
Action(s) |
Download the .java.policy file
again from the options located on the WEM splash screen.
|
Problem:
|
The WEM Process Monitoring
dialog shows “Could
not connect to server. Screen will not be invoked”.
|
Possible Cause(s): |
This may be an issue
related to JRE 1.4.x.
|
Action(s): |
If JRE 1.4.x is currently
installed, uninstall it and then install JRE 1.5 or 1.6.
|
Problem:
|
After enabling audio
support from the Alarm Management menu, the browser window crashes
with the following error message:
An unexpected exception
has been detected in native code outside the VM.
Unexpected Signal:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
at PC=0x7131B60
Function=[Unknown.]
Library=C:\Program
Files\Java\j2re1.4.2_04\bin\jsound.dll
In addition, the stack
trace output shows:
Current Java thread:
at com.sun.media.sound.MixerThread.runNative(Native Method)
at com.sun.media.sound.MixerThread.run(Unknown
Source)
|
Possible Cause(s): |
This may be an issue
related to 1.4.x.
|
Action(s): |
If 1.4.x is currently
installed, uninstall it and then, install JRE 1.5 or 1.6.
|
Issues Pertaining to WEM Upgrade
Problem:
|
The migrate script
is not working if the postgres server is running on a port other
than the default port.
|
Possible Cause(s): |
The postgres communication
port parameter is not passed to the postgres application call through
the migrate script.
|
Action(s): |
A script will prompt
you to provide inputs for the postgres communication port at the time
of data restoration (not at backup time) along with other input
parameters (backup dir, WEM application path, postgres admin, password).
|
Problem:
|
Map could not be fetched
after manual upgrade to another version.
|
Possible Cause(s): |
While manually upgrading
from version 'A' to version 'B', you may have used the original
migrate script from version 'A' (since it is already available on
the system) to restore the database.
|
Action(s): |
While manually upgrading
from version 'A' to version 'B', if you use the migrate script from
version 'A', the database will be backed up. However, to restore
the database, you have to use the migrate script from version 'B.’ That
is the script packaged with the version that you are upgrading to.
You will get the latest
migrate scripts for restoring the database after unpacking the lastest
WEM installation zip file. The reason for doing this is that the
recent scripts are likely to be upgraded from previous versions.
|
img.html
with imgdebug.html
.
Capturing WEM Server Logs using Script
Requirements
./getSupportDetails.pl [--level=...] [--xmlfile=...] [--outputDir=] [--help]
--level |
Specifies the level
of debug to run. It can have a maximum of 4 levels. The level 4
provides the most detailed information. Refer to README.txt file
for more information.
Default: 1
|
--xmlfile |
Specifies the xml file
name to be used for collecting the log.
Default: getSupportDetails.xml
|
--outputDir | Specifies the output directory for the emssupportDetails.tar.gz file if different from the default output directory (/tmp/). |
--help |
Display this information.
|
./serv stop
ifconfig bge0 192.168.1.1
netmask 255.255.255.0 up
vi nms.cfg
Replace
the IP address with the new IP address in the modify serverIpAddress
field. For example:
ServerIpAddress = 192.168.1.1
Save the file after
making the appropriate changes.
# cat /etc/hosts
<IP address> localhost
<new_IP_address>
solaris_hostname
#
./serv start
IMPORTANT: