Open System Services Management and Operations Guide (G06.30+, H06.08+, J06.03+)

Both the primary and backup OSS name server processors for a fileset can fail during the restart.
If both the primary and backup OSS name server processors for a fileset fail, the OSS Monitor
checks processor messages until one of the OSS name server processors is reloaded, then initiates
the recovery sequence. You do not need to take any action.
If a restart operation fails for a fileset, that fileset, which was in the STARTED state, is changed to
the UNKNOWN state by the OSS Monitor. You can use the SCF STATUS FILESET command to
determine which filesets remain in the UNKNOWN state after the failure of an automatic fileset
restart sequence.
The FSCK integrity checker also might fail during a restart. For example, if the FSCKCPU value for
the OSS Monitor specifies a different processor than the processor that the OSS Monitor is running
on, the specified processor could have 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” (page 285)).
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.
nn
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” (page 160) 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.
Auditing a Fileset
An important component of a secure file system is the ability to trace the history of security-related
operations on objects in the system. OSS security auditing allows you to collect a history of audited
operations—that is, an audit trail—on a specified set of auditable objects in the system.
Auditing a Fileset 149