Open System Services Management and Operations Guide (G06.29+, H06.07+)

ManualsBrandsHP ManualsServerHP NonStop G-Series

161

162

163

164

165

166

167

168

169

170

Managing Filesets

Open System Services Management and Operations Guide—527191-005

5-11

Potential Problems During Automatic Restart of

Filesets

failed. The OSS Monitor reinitiates the fileset restart sequence when the specified

FSCK processor is reloaded.

You might not want to wait for the FSCK processor to be reloaded. You can correct this

situation manually by changing the FSCKCPU value (See ALTER SUBSYS, ALTER

MON, and ALTER PROCESS Commands on page 12-34).

If the recovery sequence does not begin automatically, you can perform it manually by

issuing commands with the following format at an SCF prompt:

DIAGNOSE FILESET filesetname, CPU nn, REPAIR SERIOUS

filesetname

is the name of a stopped fileset. For greatest efficiency, you should specify filesets

in the correct order for mounting, beginning with the root fileset.

is the processor number of the processor used by the OSS Monitor. You know that

this processor is not reloading. By specifying a processor in the command, you

override the processor number specified in the subsystem configuration.

This command runs the FSCK integrity checker. When FSCK finishes successfully, the

fileset is placed in the STOPPED state. If FSCK fails, the fileset is put back in the

UNKNOWN state.

If FSCK fails:

1. Check the EMS log for messages related to the DIAGNOSE FILESET command.

2. If necessary, purge the FSCK log file. (See FSCK Log File on page 5-25 to help

locate the FSCK log file.)

3. Reissue the DIAGNOSE FILESET command.

If the DIAGNOSE FILESET command finishes successfully:

1. Verify that at least one of the OSS name server processors for that fileset is

running.

2. Issue the following SCF command:

START FILESET $ZPMON.ROOT

3. Restart every fileset that was in the STARTED state.

A quicker alternative to recovering from a problem during an automatic fileset restart

sequence is:

1. Verify that at least one of the OSS name server processors is running.

2. Stop the OSS Monitor and restart it.

The OSS Monitor invokes the automatic fileset restart sequence again, and the restart

should succeed this time.