Process recovering with AltixC/R package 

Context in source publication

Context 1

... AltixC/R is the kernel-level checkpointing package designed for Altix [ 18] systems equipped with IA64 [17] processors and running under the ProPack [16] environment (a Linux-based environment prepared by SGI). Versions of the package that works with ProPack based on Linux kernel 2.4 as well as with a more recent ProPack that is based on Linux kernel 2.6 [19] [20] are currently available. The package is characterized by all features typical for kernel-level approach. It is easy to use, there is no assumption on the availability of source codes or the programming language that was used to write the programs that are to be checkpointed. The package has to be deployed by the system administrator. The package allows doing checkpoints of multi-process programs that communicate through System V IPC objects. Additionally, the idea of virtualization of some system global keys and identifiers has been employed in that product. Thanks to that, when the program is recovered, it is cheated that the identifiers have not changed [8] (even though, due to technological reasons, it is very likely that they have). The package has been developed as part of the SGIGrid project [9]. The workflow of checkpointing and recovery activity is essential from the point of view of integration. Therefore the way the checkpoint is taken and the process is recovered by AltixC/R is presented below. The AltixC/R allows taking checkpoints of any processes that adhere to imposed limitations, i.e. the processes that use only the resources that are supported by AltixC/R. It is not important in what language the process that is being checkpointed has been written. The checkpointed process is totally independent of the checkpointing tools. It means that the process does not have any hooks or other common elements with the AltixC/R package. Actually the being checkpointed process is completely unaware of the existence of the checkpointing tool. The tools, resources and sequence of the steps involved in the process of taking the checkpoint are presented in figure 1. When the user decides to take checkpoint, he/she executes the ”chkpnt < PID > ” command (where < PID > specifies the process being checkpointed). With help of the system calls, the procfs filesystem and special proprietary kernel modules ( syscover and ckpt modules) the chkpnt command saves the image of the process defined by PID into the file. What is important, the whole operation is transparent to the process being checkpointed and there is no way to force the process to perform some special procedures before and just after the checkpoint is done. It means that the being checkpointed process releases and reallocates non-checkpointable resources when necessary. The recovering procedure is also completely transparent to the process being recovered. The resources, tools and the sequence of operations involved in the recovering process are presented in figure 2. In order to recover the process, the user has to execute the ”resume < image > ” command, where < image > is the path to the image of the checkpointed process. To obtain the ”frame” of the process being recovered, the resume command ”forks” itself. Further, using the available system calls, the procfs filesystem and proprietary kernel modules the resume command replaces the memory space and other resources of the just forked process with those saved in the checkpoint image. Finally, the resume command finishes execution and the just recovered process begins to be executed from the point where the checkpoint was taken. The recovered process has no possibility to interact with the recovery command, so registering and invoking of any callbacks is not possible (from TCKPT point of view it is very important ...