JP2000322274A - Hierarchical recovery device for operating system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a hierarchical recovery device for operating system which can avoid system down and minimizes the influence of a fault. SOLUTION: If a trap handler 3 judges that restoration with a recovery routine 11 is necessary when an exception is generated due to wrong address reference of modules 1 which is modularized for each function and which are provided with the recovery routine 11, a module which is the cause of the exception is specified by a recovery manager 4, and the recovery routine 11 of the module 1 is executed, and initialization or partial disconnection of a faulty part is executed by the recovery routine 11 to try the restoration of the entire system. It restoration is impossible in this case, a recovery routine 21 of a sub-system 2 to which the module 1 belongs is executed to perform the initialization or disconnection of the faulty part.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention provides a method for performing a recovery process hierarchically from a location where a failure has occurred in the event of a failure of an operating system, minimizing the influence of the failure and reducing the entire system down. The present invention relates to a hierarchical recovery device of an operating system for avoiding a failure.

[0002]

2. Description of the Related Art As is well known, an operating system is the most basic shiftware required when operating a computer. This shiftware is a common standard for software when using a computer, is used by all users of computers, and is software that belongs to a technically advanced and special field. A computer is operated by applying various applications to an operating system.

[0003]

The conventional operating system has the following problems. That is,
When a certain module refers to an illegal address, the whole system goes down. Even if this module has nothing to do with the main task of the system, and if the operation of this module itself stops working but the whole system has little effect, the whole system will go down and the system There was a problem that also stopped the main task of.

As an approximation technique, for example, Japanese Patent Application Laid-Open No. 62-276652 discloses a system for preventing a system from being down when an error occurs due to erroneous processing of communication control means for controlling a terminal device by a communication communication control program. A function recovery method that enables continuous operation of the system by removing the factors is disclosed.However, the recovery processing is performed hierarchically from the location where the failure occurred, minimizing the impact of the failure, There is no teaching about enabling the avoidance of downtime.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned conventional problems. In the prior art, it is possible to avoid a failure in which the entire system has been down, and to perform a hierarchical restoration to thereby prevent the failure. It is an object of the present invention to provide an operating system hierarchical recovery apparatus capable of minimizing the influence of the above.

Further, according to the present invention, when a failure is detected at a module level, even if the cause of the failure is a subsystem-level failure that cannot be resolved within the module, an operating system capable of recovering by a hierarchical recovery routine. It is an object of the present invention to provide a hierarchical recovery apparatus for a system.

[0007]

In order to achieve the above object, a hierarchical recovery apparatus for an operating system according to the present invention is included in a kernel section of an operating system, and refers to an illegal address by a module that is modularized for each function. And the trap handler that determines whether recovery by the recovery routine is necessary when an exception occurs, and the module that caused the exception when the trap handler determines that recovery is necessary. A recovery manager that identifies and executes a recovery routine for the module, including the module,
A sub-system for executing a recovery routine provided by itself when recovery is not performed by execution of the recovery routine. Therefore, if an exception occurs due to a reference to an illegal address in the module, the trap handler included in the kernel part of the operating system determines whether or not recovery is necessary by a recovery routine, and as a result of the determination, recovery is If necessary, the trap handler passes control to the recovery manager, which identifies the module that caused the exception, executes the module's recovery routine, and prevents the entire system from going down. However, if recovery is not possible, the system executes the recovery routine of the subsystem to which the module belongs. Can be stopped.

The hierarchical recovery apparatus for an operating system according to the present invention is included in a kernel section of the operating system and is modularized for each function.
A module for determining whether recovery by a recovery routine is necessary when an operating system failure is detected,
If the module determines that the recovery is necessary, execute the recovery manager that executes the recovery routine of the module and the recovery routine that includes the module and that is provided when the recovery is not performed by executing the recovery routine. And a subsystem that performs Therefore, when a module detects a failure, the recovery manager executes the module's recovery routine and attempts to recover from the failure when it determines that recovery is necessary according to its recovery routine. When it is determined that the failure is caused by the failure at the module level, the recovery routine of the subsystem to which the module belongs is executed to avoid the failure. Even a subsystem-level failure that cannot be resolved within the system can be recovered by a hierarchical recovery routine.

[0009]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, an embodiment of a hierarchical recovery apparatus for an operating system according to the present invention will be described with reference to the drawings. FIG. 1 shows a first embodiment of the present invention.
FIG. 2 is a functional block diagram showing a configuration of the embodiment. In FIG. 1, the kernel part of the operating system includes a module 1, a subsystem 2, a trap handler 3, and a recovery manager 4. The module 1 has a module recovery routine 11 and the subsystem 2 has a subsystem recovery routine 21.

The module 1 is modularized for each function. The subsystem 2 groups related modules, controls them, and provides a certain set of functions. In the subsystem 2, a plurality of modules same as the module 1 are arranged. Further, there are cases where a plurality of subsystems 2 are arranged, and the first embodiment shown in FIG. 1 illustrates a case where three subsystems 2 are arranged. Others have been added.

Since these subsystems 2a and 2b have the same configuration as the subsystem 2, the subsystem 2
The same reference numerals as in FIG. 1 denote the same parts, and the same reference numerals are added to the letters “a” and “b”. When an exception occurs, the trap handler 3 processes the exception. The recovery manager 4 is called from the trap handler 3 when recovery is necessary, and controls the execution of the recovery routine 11 and the recovery routine 21.

Next, the operation of the first embodiment will be described in detail with reference to the flowcharts of FIGS. For example, when an illegal address is referenced in module 1 which is a LAN driver and an exception occurs (see FIG. 2).
Step A1), the trap handler 3 determines whether or not recovery by the recovery routine is necessary (Step A).
2). As a result of this determination, if recovery is necessary, the trap handler 3 passes control to the recovery manager 4.

As a result, the recovery manager 4 specifies the module that caused the exception, and executes the recovery routine 11 of the module 1 (step A3). In the recovery routine 11, an initialization process is performed or a faulty part is partially separated to prevent the whole system from going down and to attempt recovery. By performing this recovery,
A determination is made in the recovery routine 11 as to whether or not the recovery was successful (step A4). As a result of the determination, if it is determined that the recovery is not possible, the recovery routine of the subsystem 2 to which the module 1 belongs, for example, the network subsystem 21 is executed (step A5).

The recovery routine 21 performs an initialization process or separates a failed part. For example, the entire network is initialized or the network is stopped. The recovery manager 4 determines whether or not the operation has been recovered by the above operation. If it is determined that the recovery has been performed (step A6), the system is prevented from being down while minimizing the influence of the failure. Then, a series of processes is completed. If it is determined that the restoration has not been completed, the execution is performed by the existing trap handler (step A7), and it is again checked whether or not the restoration in step A2 is necessary. Return to the processing to be performed.

Next, a second embodiment of the present invention will be described with reference to the drawings. FIG. 3 is a functional block diagram showing the configuration of the second embodiment. In the case of the second embodiment shown in FIG. 3, the recovery manager 4
The difference is that the module 1 operates on the extension in which the failure is detected, instead of operating on the extension of the exception. Other parts are the same as those of the first embodiment shown in FIG.

Next, the operation of the second embodiment will be described with reference to the flowchart of FIG. In FIG. 4, when the module 1 detects a failure (step A11 in FIG. 4), the module 1 determines whether recovery by the recovery routine 11 is necessary (step A12).
As a result of this determination, if recovery is necessary, control is passed to the recovery manager 4. The recovery manager 4 executes the recovery routine 11 of the module 1 (Step A1)
3).

In the recovery routine 11, recovery is attempted by performing initialization processing or partially isolating a faulty part. The result of this attempt is determined (step A1
4) If it is determined that the recovery has been performed, the processing is terminated. If the recovery has not been performed, and if it is determined that a failure at the subsystem level is the cause, the recovery routine of the subsystem 2 to which the module 1 belongs. 21 is executed (step A15).

In the recovery routine 21, an initialization process is performed or a faulty part is separated. With this operation, when a failure is detected at the module level, even if the cause of the failure is a subsystem-level failure that cannot be resolved within that module, recovery can be performed by a hierarchical recovery routine.

[0019]

As described above, according to the present invention, when an illegal address is referred to in the module and it is determined by the trap handler that recovery is required by the recovery routine when an exception occurs, the recovery manager causes the exception. The recovery routine of the module is specified and the recovery routine of the subsystem is executed when recovery is not possible. By implementing, it is possible to avoid this, and since the recovery means is tried hierarchically, the effect of the failure can be minimized.

According to the present invention, when the module detects a failure, the recovery manager executes the recovery routine of the module and attempts recovery from the failure when the recovery routine determines the necessity of recovery by the recovery routine. If it is determined that the failure is caused by a subsystem-level failure when recovery is not possible, the failure is avoided by executing the recovery routine of the subsystem to which the module belongs. Furthermore, even if the cause of the failure is a subsystem-level failure that cannot be resolved in the module, recovery can be performed by a hierarchical recovery routine.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing a configuration of a first embodiment of a hierarchical recovery device for an operating system according to the present invention.

FIG. 2 is a flowchart for explaining the operation of the first embodiment of the hierarchical recovery apparatus for an operating system according to the present invention;

FIG. 3 is a functional block diagram showing a configuration of a second embodiment of the hierarchical recovery apparatus for an operating system according to the present invention;

FIG. 4 is a flowchart for explaining the operation of the second embodiment of the hierarchical recovery apparatus for an operating system according to the present invention;

[Explanation of symbols]

1, 1a, 1b ... module, 2, 2a, 2b ... subsystem, 3 ... trap handler, 4 ... recovery manager, 11, 11a, 11b ... module recovery routine, 21, 21a, 21b ... subsystem Recovery routine.

Claims (14)

[Claims] 1. A trap handler that is included in a kernel section of an operating system and that determines whether or not recovery by a recovery routine is necessary when an exception occurs by referring to an illegal address in a module modularized for each function, and If the trap handler determines that the recovery is necessary, a recovery manager that identifies the module that caused the exception and executes a recovery routine of the module; A sub-system for executing a recovery routine provided by the self-executing system when recovery is not performed by execution; and a hierarchical recovery apparatus for an operating system. 2. The hierarchical recovery apparatus according to claim 1, wherein the module is a LAN driver. 3. The operating system according to claim 1, wherein the recovery manager performs an initialization process at the time of executing a recovery routine of the module to prevent the entire system from going down, and attempts recovery. Hierarchical recovery device. 4. The recovery manager according to claim 1, wherein at the time of execution of the recovery routine of the module, a fault location is partially cut off to prevent the entire system from going down.
The hierarchical recovery apparatus for an operating system according to claim 1, wherein recovery is attempted. 5. The subsystem including the module,
The hierarchical recovery device for an operating system according to claim 1, wherein the hierarchical recovery device is a network subsystem. 6. The hierarchical recovery apparatus of an operating system according to claim 1, wherein said subsystem performs an initialization process when executing a recovery routine provided in said subsystem. 7. The operating system hierarchical recovery apparatus according to claim 1, wherein said subsystem performs initialization processing of the entire network when executing a recovery routine provided therein. 8. The hierarchical recovery apparatus for an operating system according to claim 1, wherein said subsystem separates a failure point when executing a recovery routine provided in said subsystem. 9. The hierarchical recovery system for an operating system according to claim 1, wherein the subsystem stops the network when executing the recovery routine provided in the subsystem. 10. A module that is included in a kernel part of an operating system, is modularized for each function, and determines whether or not recovery by a recovery routine is necessary when a failure of the operating system is detected. If it is determined that the recovery manager executes the recovery routine of the module, and a subsystem that includes the module and executes its own recovery routine when the recovery is not performed by executing the recovery routine. Characterized hierarchical recovery device of operating system. 11. The hierarchical recovery apparatus of an operating system according to claim 10, wherein said recovery manager performs an initialization process when executing a recovery routine of said module. 12. The recovery manager according to claim 10, wherein the recovery manager attempts recovery by partially disconnecting a failure part when executing a recovery routine of the module.
A hierarchical recovery device for the described operating system. 13. The hierarchical recovery apparatus for an operating system according to claim 10, wherein said subsystem performs initialization processing of the entire network when executing a recovery routine provided in said subsystem. 14. The hierarchical recovery system for an operating system according to claim 10, wherein said subsystem isolates a failure point when executing a recovery routine provided in said subsystem.