Summary of some experiences on troubleshooting WebSphere services not starting problems

about resolving WebSphere Summary of some experiences on service not starting <?xml:namespace prefix = o ns = "Urn:schemas-microsoft-com:office:office"/>

Li Shouliang slli@founder.com.cn

Last version:2003-3-20

Briefly

The reasons that WebSphere services cannot be started are usually caused by the following conditions. There is no clean Java process; The database is not started, the database part parameter is set wrong, the database structure is broken, was connected to the database schema is inconsistent, virus, patch and other reasons. At first Webspher service can not start, had to reinstall, wasted a lot of time, took a lot of detours. When the WebSphere service fails to start, please follow the steps below to check. Typically, you can simply reinitialize the management library.

Directory

First, check if there is no clean Java process

Second, check whether the DB2 database starts normally

Third, check whether the management database was present

Iv. Check if the device holding the database is normal mount

V. Check whether the schema of the WebSphere join was library is consistent

Vi. Remediation of the Was Management database (initialization)

Vii. Check if the file vault is broken and rebuilt with was management library

Viii. Windows platform should also rule out whether the virus causes

IX. Linux platforms are usually associated with system patches

Content

First, check whether there is no clean Java process

Under Unix:

# Ps–ef | grep java

# kill–9 PID (Note Confirmation is the Java process of was)

Then restart the was service again.

#/opt/websphere/appserver/bin/startupserver sh&

# tail–f Opt/websphere/appserver/logs/tracelog

On the Windows platform, use Explorer to view and kill was Java and restart the service.

Second, check whether the DB2 database starts normally

If WebSphere uses DB2 as the management library, you should first check whether DB2 starts properly. If no boot should start it: check if there is a database mount Fsck

Under Unix:

# su–db2as

$ db2admin Start

$ su–db2inst1

$ db2start

Start from the cmd window or service under the win platform.

Third, check whether the management database was present

If the DB2 server is functioning properly, it still cannot start, and you need to check if the database exists.

Under Unix:

$ db2

=>list DB Directory

=>connect to is user <user> using <password>

View from the DB2 command widow or control Center under the window platform.

Iv. Check if the device holding the database is normal mount

If the database is not joined, one of the possible scenarios is that the database device does not mount correctly on the UNIX platform, an unhealthy shutdown, or some operation that is damaging to the disk can cause this to happen.

Use the following command to check for disks that are not on mount.

# df–k

# mount

# Mountall

# Cat/etc/vfstab

Suppose you check that the/DEV/DSK/C0T0D0S6 device does not mount correctly, use # FSCK–F/DEV/DSK/C0T0D0S6 to fix it, and then restart the server.

V. Check whether the schema of the WebSphere join was library is consistent

Phenomenon:

$ db2

=>db2

=>force Application All

#/opt/websphere/appserver/bin/startupserver sh&

Run after service starts

=>list applications

You can also list the was library that was joined, but still fail to start. At this point, confirm whether the dbuser of the WebSphere join database has been changed, because the tables created by different users in DB2 are stored under different schemas, if the original initialization succeeds, the connection is normal, and for some reason (such as secrecy), the user of the WebSphere join was library is removed. Causing WebSphere to find no initialization table, causing the service to fail to start.

There are two ways to solve this problem:

A), modified back to the original Dbuser, in the/opt/websphere/appserver/bin/admin.config (win version in the relevant directory), related lines:

Com.ibm.ejs.sm.adminserver.dbuser=

Com.ibm.ejs.sm.adminserver.dbschema=

II), reinitialization of the management database

1. Prior to WebSphere version 3.54 (included)

1), modify the/opt/websphere/appserver/bin/admin.config (win version in the relevant directory):

Install.initial.config=false modified to True

2), #/opt/websphere/appserver/bin/startserver.sh &

2, WebSphere 3.55, 3.56 version, relative to the 3.54 version made a relatively large change

1), modify the/opt/websphere/appserver/bin/admin.config (win version in the relevant directory):

Install.initial.config=false modified to True

Also want to modify

Com.ibm.ejs.sm.adminserver.dbinitialized=true Change to False

2), #/opt/websphere/appserver/bin/startserver.sh &

Vi. Remediation of the Was Management database (initialization)

There is no schema problem with the File Management library (INSTDB), but sometimes setting environment variables can still cause the was service to fail to start, so the management library needs to be repaired so that some startup parameters are returned to the initialization state. After the management library is initialized, some settings that are irrelevant to the initial parameters remain. You can save some time to reset. But if there is a problem with irrelevant settings, you only have to re-build the management library.

For the DB2 Management library, and the file management library using Instdb, this method applies:

A), prior to WebSphere version 3.54 (included)

1, modify the/opt/websphere/appserver/bin/admin.config (win version in the relevant directory):

Install.initial.config=false modified to True

2. #/opt/websphere/appserver/bin/startserver.sh &

II), WebSphere 3.55, 3.56 version, compared to the 3.54 version made a relatively large change, so pay special attention to

1, modify the/opt/websphere/appserver/bin/admin.config (win version in the relevant directory):

Install.initial.config=false modified to True

Also want to modify

Com.ibm.ejs.sm.adminserver.dbinitialized=true Change to False

2. #/opt/websphere/appserver/bin/startserver.sh &

Vii. Check if the file vault is broken and rebuilt with was management library

Verify that the database is corrupted and the following work is to re-create the library and reinitialize it. (The earliest time, because do not know the cause of the problem, had to re-install, took a lot of detours). In Xiangyu enp2000 server also encountered a INSTDB file vault corruption caused by WebSphere can not start an accident. The solution is listed as follows:

A), DB2 database, the UNIX platform as an example:

1. Delete Database

# Su–db2inst1

$ db2

=>disconnect All

=>force Application All

=>termenate

$ DB2 Drop DB was

2. Create a database

$ db2

=>create DB was

=>update db CFG for is using APPLHEAPSZ 256

3, modify Admin.config, database initialization

1), prior to WebSphere 3.54 (included)

A, modify/opt/websphere/appserver/bin/admin.config

Install.initial.config=false modified to True

B, #/opt/websphere/appserver/bin/startserver.sh &

2), WebSphere version 3.55, 3.56

A, modify/opt/websphere/appserver/bin/admin.config

Install.initial.config=false modified to True

Also want to modify

Com.ibm.ejs.sm.adminserver.dbinitialized=true Change to False

B, #/opt/websphere/appserver/bin/startserver.sh &

ii), File management library

1. Delete Database

To delete or rename a vault directory:

# Rm–r/opt/websphere/appserver/bin/idbstore or

# Cd/opt/websphere/appserver/bin/idbstore

# mv./idbstore./idbstore.bak

2, modify Admin.config, database initialization

1), prior to WebSphere 3.54 (included)

A, modify/opt/websphere/appserver/bin/admin.config

Install.initial.config=false modified to True

B