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

Managing Filesets
Open System Services Management and Operations Guide—527191-005
5-10
Automatic Restart of Filesets After OSS Name
Server Failure
The automatic startup service can also restart the fileset a maximum number of times
during a 10-minute period. See the ADD FILESET Command on page 12-7 or the
ALTER FILESET Command on page 12-20 for more information about this service.
Automatic Restart of Filesets After OSS Name Server Failure
If an OSS name server fails, the OSS Monitor initiates a recovery procedure similar to
that performed during OSS Monitor startup. All filesets that were left in the STARTED
state and were managed by that OSS name server (as the OSS name server for either
the fileset or the mount-point) are repaired and restarted. The OSS Monitor also
restarts that OSS name server.
Automatic Restart of OSS Name Servers After Processor Failure
If failure of a processor causes failure of an OSS name server process running without
a backup or causes termination of a fault-tolerant OSS name server process pair, the
OSS Monitor initiates a recovery procedure similar to that performed upon OSS
Monitor startup. No recovery is attempted if the processor failure only affects one
process of the OSS name server process pair.
During the recovery, all filesets that were left in the STARTED state and were managed
by the failed OSS name server (as the OSS name server for either the fileset or the
mount-point) are repaired and restarted. The OSS Monitor also restarts that OSS name
server.
Potential Problems During Automatic Restart of Filesets
The OSS Monitor might be unable to successfully restart all filesets that were left in the
STARTED state when their OSS name servers failed. If a failure occurs, you can
attempt to manually recover from that failure.
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
Note. When the OSS Monitor attempts automatic restart of filesets, it does not retry if certain
failures occur.