CN109726050B - 一种进程修复的方法和装置 - Google Patents

Abstract

本申请提供一种进程修复的方法，操作系统级虚拟环境OVC包括公共OVC和至少一个普通OVC，所述方法包括：在接收进程修复指令后，可以通过公共OVC解析该进程修复指令，以确定待修复进程，而后，确定出该待修复进程所属的至少一个普通OVC的OVC标识。针对确定出的每个普通OVC的OVC标识，根据该进程修复指令，通过公共OVC中的管理进程对该待修复进程进行修复，得到修复后进程，并将该修复后进程所属的OVC的OVC标识修改为该OVC标识，重启修改了所属OVC的OVC标识后的修复后进程，从而实现了进程的动态修复，保证了在进程修复过程中用户执行的业务不会中断。

Description

一种进程修复的方法和装置

技术领域

本申请涉及计算机技术领域，特别涉及一种进程修复的方法和装置。

背景技术

操作系统级虚拟环境(OS-Level Virtual Context，OVC)是一种将一台物理设备虚拟成多台逻辑设备的虚拟化技术。经过OVC虚拟化之后，同一台物理设备上的多个逻辑设备都拥有独立的硬件、软件、管理平面和日志，各逻辑设备的运行互不影响。OVC技术实现了资源和管理的虚拟化，物理设备资源池化后，业务的快速部署和调整不再受限于物理设备本身，实现了节约建设和运维成本、灵活按需部署、安全故障隔离等优点，有效地解决了多业务安全隔离和资源按需分配的问题。

OVC通常可以分为公共OVC以及普通OVC，其中，系统初始状态存在的默认OVC称之为公共OVC，系统内所有资源归公共OVC统一使用。公共OVC以外的其他OVC则称之为普通OVC，普通OVC所使用的资源是从系统中划分出来的，而在创建普通OVC后，系统内没有划分到普通OVC的资源都属于公共OVC。

网络设备在实际的运行中不可避免会因软件缺陷而出现运行故障，在实际应用中，通常通过两种解决方式应对该运行故障：升级版本以及打热补丁。如果通过升级版本的方式修复运行故障，则需要重启设备，则势必会造成较长时间的业务中断，从而给用户的业务执行带来一定的不便。而使用打热补丁的方式修复运行故障，无需进行设备重启，从而实现了在不影响在线业务的情况下，动态地完成了运行故障的修复。

当公共OVC中进程出现故障时，可以通过打热补丁的方式对该进程进行修复，但是若是普通OVC中的进程出现故障时，则无法通过打热补丁的方式对其进行修复，只能通过升级版本的方式，来对所有OVC中的该进程进行修复，这样将会造成业务中断，从而给用户的业务执行带来不便。所以，如何能够使用打热补丁的方式对普通OVC中出现故障的进程进行修复，则是一个亟待解决的问题。

发明内容

有鉴于此，本申请提供一种进程修复的方法和装置，可以通过打热补丁的方式对所有OVC中的进程进行修复。

具体地，本申请是通过如下技术方案实现的：

一种进程修复的方法，操作系统级虚拟环境OVC包括公共OVC和至少一个普通OVC，包括：

公共OVC对接收到的进程修复指令解析，确定待修复进程；

确定所述待修复进程所属的至少一个普通OVC的OVC标识；

针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述公共OVC中的管理进程对所述待修复进程进行修复，得到修复后进程，并将所述修复后进程所属OVC的OVC标识修改为该OVC标识；

重启修改了所属OVC的OVC标识后的修复后进程。

一种进程修复的装置，操作系统级虚拟环境OVC包括公共OVC和至少一个普通OVC，所述装置包括：

解析单元，用于对接收到的进程修复指令解析，确定待修复进程；

确定单元，用于确定所述待修复进程所属的至少一个普通OVC的OVC标识；

修复单元，用于针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述装置中的管理进程对所述待修复进程进行修复，得到修复后进程，并将所述修复后进程所属OVC的OVC标识修改为该OVC标识；

重启单元，用于重启修改了所属OVC的OVC标识后的修复后进程。

由以上本申请提供的技术方案可见，在接收进程修复指令后，可以通过公共OVC解析该进程修复指令，以确定待修复进程，而后，确定出该待修复进程所属的至少一个普通OVC的OVC标识。针对确定出的每个普通OVC的OVC标识，根据该进程修复指令，通过公共OVC中的管理进程对该待修复进程进行修复，得到修复后进程，并将该修复后进程所属的OVC的OVC标识修改为该OVC标识，重启修改了所属OVC的OVC标识后的修复后进程，从而实现了进程的动态修复，保证了在进程修复过程中用户执行的业务不会中断。

附图说明

图1为本申请实施例示出的进程修复的过程示意图；

图2为本申请示出的进程修复的详细过程示意图；

图3为本申请示出的一种进程修复的装置的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在实际应用中，通常需要调用公共OVC中的管理进程对需要修复的进程打热补丁修复，但是，若是需要修复的进程归属于普通OVC，则修复后进程重启后将不再归属该普通OVC。这是因为，进程启动时会默认归属于父进程所属的OVC，当通过调用公共OVC中的管理进程修复普通OVC中的待修复进程时，管理进程为该待修复进程的父进程，所以，一旦将修复后进程进行重启，则该修复后进程将与管理进程一样归属于公共OVC，并在公共OVC中进行运行，这样将会造成普通OVC中进程的缺失。

为了避免上述情况的发生，在本申请实施例中，在对待修复进程进行修复时，可以先确定出该待修复进程所属的至少一个普通OVC的OVC标识，然后通过调用公共OVC中的管理进程，对该待修复进程进行修复，并根据确定出的该待修复进程所属的普通OVC的OVC标识，将修复后进程所属OVC的OVC标识修改为该OVC标识，并对该修复后进程进行重启。

换句话说，在修复该待修复进程之前，先确定出该待修复进程所归属的OVC的OVC标识，而后在通过公共OVC中的管理进程对该待修复进程进行修复后，不再按照该管理进程所属的公共OVC确定该待修复进程的归属，而是根据先前确定出的OVC标识，确定该待修复进程所属的OVC，从而保证了待修复进程修复并重启后依然运行在其先前所属的OVC中。

图1为本申请实施例示出的进程修复的过程示意图，具体包括以下步骤：

S101：公共OVC对接收到的进程修复指令解析，确定待修复进程。

在实际应用中，可以供运维人员调用打热补丁的管理进程属于公共OVC，因此，运维人员在确定各OVC中运行的进程出现故障时，可以编写进程修复指令，并输入到公共OVC中。该公共OVC可以接收该进程修复指令，并对该进程修复指令进行解析，以确定需要修复的待修复进程。其中，该公共OVC可以运行在设备中，这里提到的设备可以是电脑、服务器等。

在本申请实施例中，该进程修复指令可以是指能够在Linux的shell脚本中单独执行的Linux指令。公共OVC在接收到该进程修复指令后，可以通过其运行的Linux的shell脚本执行解析该进程修复指令，以确定需要修复的待修复进程。例如，若该进程修复指令为：ovc restart process name，则该公共OVC可以利用Linux中预设的解析Linux指令的方法，利用argc来确定该进程修复指令中参数的个数，确定出的process name即为需要进行修复的待修复进程的名称，从而根据确定出的待修复进程的名称，确定待修复进程。

S102：确定所述待修复进程所属的至少一个普通OVC的OVC标识。

在本申请实施例中，预先保存有进程列表，该进程列表中保存有各OVC的OVC标识和各OVC所能运行的各进程的进程标识的对应关系。例如，该进程列表中记录有ovc id和process name的对应关系，其中，ovc id即为OVC标识，process name为进程的名称，可以看作是进程标识。

公共OVC可以通过查询该进程列表中记录的各OVC标识和各进程标识的对应关系，确定出该待修复进程归属于哪些OVC。

需要说明的是，该进程列表可以是预先确定并保存的，也可以是在确定需要进行进程修复时，通过各进程与各OVC的从属关系进行注册的。当然，具体在何时注册该进程列表没有具体的限制，可以在接收到进程修复指令时注册该进程列表，也可以是在确定出待修复进程后注册该进程列表。

S103：针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述公共OVC中的管理进程对所述待修复进程进行修复，得到修复后进程，并将所述修复后进程所属OVC的OVC标识修改为该OVC标识。

S104：重启修改了所属OVC的OVC标识后的修复后进程。

在确定出该待修复进程所属的各普通OVC后，公共OVC可以将该待修复进行修复，其中，上述进程列表中除了记录有各OVC标识和各进程标识的对应关系，还记录有各进程在各OVC中的进程关闭方法以及进程重启方法。例如，在该进程列表中记录有ovc id，processname，ovc open process，ovc close process这一对应关系，其中，ovc id为OVC标识，process name为该OVC标识对应的OVC所能运行的进程的进程标识，ovc open process为该进程在该OVC下重启的具体方式，即，该进程如何在该OVC中进行重启，而ovc closeprocess则为该进程在该OVC中关闭的具体方式，即，该进程如何在该OVC中进程关闭。

由于在对进程进行修复时，需要先将其进行关闭，然后再对其进行修复，最后需要将修复后进程进行重启，才能将修复后进程重新进行部署。所以，在本申请实施例中，公共OVC可以针对该待修复进程所属的每个普通OVC，从上述进程列表中确定出该待修复进程在该普通OVC中具体的进程关闭方法以及进程重启方法，而后，可以通过该进程关闭方法，将该待修复进程进行关闭，然后通过进程修复指令，对该待修复进程进行修复，得到修复后进程，即，通过打热补丁的方式，对该待修复进程进行文件替换，以完成该待修复进程的修复，最后，通过确定出的进程重启方法，将修复后进程进行重启，从而完成对该待修复进程的修复。

在本申请实施例中，每个OVC中都设有重启开关，该重启开关的开闭状态表示是否允许OVC中运行的进程的在该OVC中进行重启。例如，假设普通OVC1中的进程的重启开关处于关闭状态，则表示该普通OVC1中所能运行的进程不能在该普通OVC1中进行重启，而若该重启开关处于开启状态，则表示该普通OVC1中所能运行的进程能够在该普通OVC1中进行重启。

相应的，在上述进程列表中还记录了各OVC的进程的重启开关开闭状态，例如，在ovc id，process open flag这两者的对应关系中，ovc id即为OVC标识，而process openflag即为用于表示该OVC标识对应OVC的进程的重启开关的开闭状态的开闭信息。针对每个普通OVC，可以根据该进程列表，确定出该普通OVC的进程的重启开关的开闭状态，进而根据确定出的开闭状态，确定是否需要修复该普通OVC中运行的待修复进程。

具体的，针对每个普通OVC，若是通过从该进程列表中记录的各OVC的进程的重启开关的开闭状态，确定出该普通OVC的重启开关处于开启状态，则可以确定能够对该普通OVC中运行的待修复进程进行修复，进而可以通过该进程列表中记录的该待修复进程在该普通OVC中的进程重启方法、进程关闭方法，以及进程修复指令，对该待修复进程进行修复。

而若通过进程列表，确定出该普通OVC的重启开关处于关闭状态，则可以确定无法对该普通OVC中运行的待修复进程进行修复，进而切换至下一个普通OVC中，以确定是否能够对该下一个普通OVC中所运行的该待修复进程进行修复。其中，由于在修复该待修复进程的过程中，需要重启才能将修复后进程进行部署，所以，若是确定该普通OVC不允许对其所能运行的进程进行重启，则可以认定该普通OVC不允许对其所能运行的进程进行修复。

当然，上述重启开关除了可以用于表示是否允许OVC中所能运行的所有进程进行重启外，还可以用于表示某一进程在该OVC中是否允许重启。即，上述说明的进程重启开关可以用于应对两种情况，一种是针对一个OVC中所有的进程设置一个重启开关，若是该重启开关处于开启状态，则表明该OVC中的所有进程都可以重启，反之则表明该OVC中的所有进程都不能重启。另一种是可以针对每个进程在该OVC中设置一个重启开关，若是该重启开关处于开启状态，则表明该进程可以在该OVC中进行重启，反之则表明该进程不能在该OVC中进行重启。

在本申请中，上述提到的重启开关的开闭状态可以是人为进行确定的，即人工控制重启开关的开闭，当然也可以由设备进行控制。当设备中运行的某一OVC监测到其所支持的业务在执行过程中出现故障，则可以将该OVC中设置的重启开关进行开启，而当该OVC监测到其所支持的业务在执行过程中没有任何故障，则可以将该OVC中设置的重启开关进行关闭。

为了防止因调用公共OVC中的管理进程对待修复进程进行修复而导致的修复后进程归属于该管理进程所属的公共OVC的情况发生，所以，针对确定出的每个普通OVC的OVC标识，在得到修复后进程后，可以将该修复后进程所属的OVC的OVC标识修改为该OVC标识。

换句话说，在对普通OVC中的待修复进程进行修复后，可以将该修复后进程所属的OVC标识修改为该普通OVC的OVC标识，相当于，通过公共OVC中的管理进程对该待修复进程进行修复时，已将该待修复进程所属的OVC的OVC标识修改为公共OVC的OVC标识，而通过修改OVC标识的方式，可以将得到的修复后进程的OVC标识再修改回该普通OVC的OVC标识。这样后续将该修复后进程进行重启后，该进程将依然属于该普通OVC，而不会因为修复过程中所调用的公共OVC中的管理进程，继承该管理进程所属的OVC，从而使得采用打热补丁的方式对进程修复时不会造成普通OVC中的进程缺失，保证了在进程修复过程中用户执行的业务不会中断。

为了进一步说明本申请提供的进程修复方法，下面将结合实际对整个过程进行说明，如图2所示。

图2为本申请示出的进程修复的详细过程示意图。

公共OVC可以接收进程修复指令，并通过Linux预设的解析指令方法，对该进程修复指令进行解析，以确定出该进程修复指令所针对的待修复进程。而后，可以查询预先确定出的进程列表，以确定出该待修复进程所属的OVC，该待修复进程所属OVC的重启开关是否开启，该待修复进程在其所属OVC中的进程关闭方法以及进程重启方法。

其中，进程列表中详细记录了的各OVC、各进程、各进程在各OVC中的进程关闭方法和进程重启方法，以及各OVC中的重启开关的开闭状态这五者的对应关系，如图2中所示。可以通过遍历该进程列表，确定出待修复进程都属于哪些OVC，在各个OVC中的进程关闭方法以及进程重启方法。

在确定出该待修复进程所对应的各项信息后，则可以将该待修复进程进行修复。具体的，当对某一普通OVC中的该待修复进程进行修复时，可以根据从上述进程列表中确定出的该普通OVC中重启开关的开闭状态，确定是否允许在该普通OVC中重启(也即修复)该待修复进程。若允许，则调用从上述进程列表中确定出的该待修复进程在该普通OVC中的进程关闭方法、进程重启方法以及进程修复指令，对该待修复进程进行修复，得到修复后进程，并将该修复后进程所属OVC的OVC标识修改为该普通OVC的OVC标识。

在该普通OVC中修复完该待修复进程后，可以进一步判断是否有其他OVC中的该待修复进程进行修复，若是，则重复上述步骤，对该待修复进程进行修复，若发现没有OVC中的该待修复进程需要修复，则确定完成在所有OVC中对该待修复进程进行修复的工作。

图3为本申请示出的一种进程修复的装置的示意图，该装置包括：解析单元310，确定单元320，修复单元330，重启单元340。

其中，解析单元310，对接收到的进程修复指令解析，确定待修复进程；确定单元320，用于确定所述待修复进程所属的至少一个普通OVC的OVC标识；修复单元330，用于针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述装置中的管理进程对所述待修复进程进行修复，得到修复后进程，并将所述修复后进程所属OVC的OVC标识修改为该OVC标识；重启单元340，用于重启修改了所属OVC的OVC标识后的修复后进程。

在本实施例中，所述确定单元320，具体用于通过查询预先保存的进程列表，确定所述待修复进程所属的至少一个普通OVC的OVC标识，其中，所述进程列表中记录有各OVC的OVC标识和各OVC所能运行的各进程的进程标识的对应关系。

在本实施例中，所述进程列表中还记录有各进程在各OVC中的进程关闭方法以及进程重启方法；

所述修复单元330，具体用于查询所述进程列表，确定所述待修复进程在该OVC标识对应的普通OVC中的进程关闭方法以及进程重启方法；通过所述进程关闭方法，关闭所述待修复进程；根据所述进程修复指令，对所述待修复进程进行修复，得到修复后进程；

所述重启单元340具体用于：通过所述进程重启方法，重启所述修复后进程。

在本实施例中，所述确定单元320在所述修复单元330针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述装置中的管理进程对所述待修复进程进行修复之前，具体用于根据所述进程列表，确定允许在该OVC标识对应的普通OVC中重启所述待修复进程。

在本实施例中，针对每个OVC，所述进程列表中还记录有该OVC的进程的重启开关的开闭状态，所述重启开关的开闭状态用于表示是否允许重启OVC中运行的进程；

所述确定单元320，具体用于若根据所述进程列表确定该OVC标识对应的普通OVC的进程的重启开关处于开启状态，则确定允许在该普通OVC中重启所述待修复进程。

在本实施例中，所述确定单元320，具体用于若根据所述进程列表确定该OVC标识对应的普通OVC的进程的重启开关处于关闭状态，则确定不允许在该普通OVC中重启所述待修复进程。

在本实施例中，所述装置通过Linux的shell脚本执行所述进程修复指令。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

1.一种进程修复的方法，操作系统级虚拟环境OVC包括公共OVC和至少一个普通OVC，其特征在于，包括：

公共OVC对接收到的进程修复指令解析，确定至少一个待修复进程；

针对每个待修复进程，分别记录该待修复进程所属的普通OVC的OVC标识；

根据所述进程修复指令，通过所述公共OVC中的管理进程对每个待修复进程进行修复，得到修复后进程，针对每个修复后进程，将该修复后进程所属OVC的OVC标识修改为：针对对应的待修复进程所记录的OVC标识；

重启修改了OVC标识后的修复后进程。

2.根据权利要求1所述的方法，其特征在于，针对每个待修复进程，分别记录该待修复进程所属的普通OVC的OVC标识，具体包括：

针对每个待修复进程，通过查询预先保存的进程列表，记录该待修复进程所属的普通OVC的OVC标识，其中，所述进程列表中记录有各OVC的OVC标识和各OVC所能运行的各进程的进程标识的对应关系。

3.根据权利要求2所述的方法，其特征在于，所述进程列表中还记录有各进程在各OVC中的进程关闭方法以及进程重启方法；

根据所述进程修复指令，通过所述公共OVC中的管理进程对每个待修复进程进行修复，得到修复后进程，具体包括：

查询所述进程列表，根据每个待修复进程所属普通OVC的OVC标识，确定每个待修复进程在所属的普通OVC中的进程关闭方法以及进程重启方法；

通过确定的每个待修复进程在所属OVC的进程关闭方法，关闭每个待修复进程；

根据所述进程修复指令，对每个待修复进程进行修复，得到修复后进程；

重启修改了OVC标识后的修复后进程，具体包括：

通过确定的每个待修复进程在所属OVC的进程重启方法，重启每个修复后进程。

4.根据权利要求3所述的方法，其特征在于，根据所述进程修复指令，通过所述公共OVC中的管理进程对每个待修复进程进行修复之前，所述方法还包括：

针对每个待修复进程，根据所述进程列表，确定允许在该待修复进程所属的至少一个普通OVC的OVC标识对应的普通OVC中，重启该待修复进程。

5.根据权利要求4所述的方法，其特征在于，针对每个OVC，所述进程列表中还记录有该OVC的进程的重启开关的开闭状态，所述重启开关的开闭状态用于表示是否允许重启OVC中运行的进程；

针对每个待修复进程，根据所述进程列表，确定允许在该待修复进程所属的至少一个普通OVC的OVC标识对应的普通OVC中，重启该待修复进程，具体包括：

针对每个待修复进程，若根据所述进程列表确定该待修复进程所属的至少一个普通OVC的OVC标识对应的普通OVC的进程的重启开关处于开启状态，则确定允许在该普通OVC中重启该待修复进程。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

针对每个待修复进程，若根据所述进程列表确定该OVC标识对应的普通OVC的进程的重启开关处于关闭状态，则确定不允许在该普通OVC中重启该待修复进程。

7.根据权利要求1～6任一项所述的方法，其特征在于，通过Linux的shell脚本执行所述进程修复指令。

8.一种进程修复的装置，操作系统级虚拟环境OVC包括公共OVC和至少一个普通OVC，所述装置包括：

解析单元，用于对接收到的进程修复指令解析，确定至少一个待修复进程；

记录单元，用于针对每个待修复进程，分别记录该待修复进程所属的普通OVC的OVC标识；

修复单元，用于根据所述进程修复指令，通过所述装置中的管理进程对每个待修复进程进行修复，得到修复后进程，针对每个修复后进程，将该修复后进程所属OVC的OVC标识修改为：针对对应的待修复进程所记录的OVC标识；

重启单元，用于重启修改了OVC标识后的修复后进程。

9.根据权利要求8所述的装置，其特征在于，包括：

所述记录单元具体用于：

针对每个待修复进程，通过查询预先保存的进程列表，记录该待修复进程所属的普通OVC的OVC标识，其中，所述进程列表中记录有各OVC的OVC标识和各OVC所能运行的各进程的进程标识的对应关系。

10.根据权利要求9所述的装置，其特征在于，所述进程列表中还记录有各进程在各OVC中的进程关闭方法以及进程重启方法；

所述修复单元具体用于：

查询所述进程列表，根据每个待修复进程所述普通OVC的OVC标识，确定每个待修复进程在所述的普通OVC中的进程关闭方法以及进程重启方法；通过确定的每个待修复进程在所属OVC的进程关闭方法，关闭每个待修复进程；根据所述进程修复指令，对每个待修复进程进行修复，得到修复后进程；

所述重启单元具体用于：

通过确定的每个待修复进程在所属OVC的进程重启方法，重启每个修复后进程。

11.根据权利要求10所述的装置，其特征在于，包括：

所述记录单元在所述修复单元针对确定出的每个普通OVC的OVC标识，根据所述进程修复指令，通过所述装置中的管理进程对每个待修复进程进行修复之前具体用于：

针对每个待修复进程，根据所述进程列表，确定允许在该待修复进程所属的至少一个普通OVC的OVC标识对应的普通OVC中，重启该待修复进程。

12.根据权利要求11所述的装置，其特征在于，针对每个OVC，所述进程列表中还记录有该OVC的进程的重启开关的开闭状态，所述重启开关的开闭状态用于表示是否允许重启OVC中运行的进程；

所述记录单元具体用于：

针对每个待修复进程，若根据所述进程列表确定该待修复进程所属的至少一个普通OVC的OVC标识对应的普通OVC的进程的重启开关处于开启状态，则确定允许在该普通OVC中重启该待修复进程。

13.根据权利要求12所述的装置，其特征在于，包括：

所述记录单元具体用于：

针对每个待修复进程，若根据所述进程列表确定该OVC标识对应的普通OVC的进程的重启开关处于关闭状态，则确定不允许在该普通OVC中重启该待修复进程。

14.根据权利要求8～13任一项所述的装置，其特征在于，所述装置通过Linux的shell脚本执行所述进程修复指令。

Images