CN109656743A - 一种core文件管理方法及装置、设备、介质 - Google Patents

Abstract

本申请提供一种core文件管理方法及装置、设备、介质。core文件生成功能默认启用，所述方法包括：若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。应用本申请的实施例，无需复现进程异常问题，也能够有效地获取相应的core文件以用于定位该进程异常问题，不仅如此，还能够在更多的进程异常终止的场景下有效地获取相应的core文件。

Description

一种core文件管理方法及装置、设备、介质

技术领域

本申请涉及计算机技术领域，特别涉及一种core文件管理方法及装置、设备、介质。

背景技术

Linux操作系统和Unix操作系统中，当进程因为某些异常原因终止时，可以将该进程的虚拟地址空间中的数据及造成退出的原因、调用栈信息等记录在一个二进制文件中，即core文件。终止动作的执行是通过接收到的特定信号所触发的，比如，SIGABRT信号、SIGBUS信号等，当程序出现故障，比如，运行期间发现进程执行了错误的内存操作(访问非法内存、重复释放内存等)，则会向自己发送一个上述的特定信号，触发生成core文件并终止进程。研发人员可以利用调试工具对core文件进行分析，从而定位进程终止的具体原因。

在实际应用中，core文件生成功能默认是不启用的，在这种情况下，不会生成core文件，则若进程异常终止需要定位原因时，用户需要手动启用core文件生成功能，再复现问题，才能获得core文件；另外，对于某些进程异常终止，触发终止动作的特定信号并不会触发core文件生成，比如，SIGINT信号等。基于此，需要能够更为有效地获取core文件的方案。

发明内容

有鉴于此，本申请提供一种core文件管理方法及装置、设备、介质，以更为有效地获取core文件。

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

一种core文件管理方法，core文件生成功能默认启用，所述方法包括：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

一种core文件管理装置，core文件生成功能默认启用，所述装置包括：

第一生成模块，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

第二生成模块，若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

一种core文件管理设备，core文件生成功能默认启用，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

一种core文件管理非易失性计算机存储介质，存储有计算机可执行指令，core文件生成功能默认启用，所述计算机可执行指令设置为：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

由以上本申请提供的技术方案可见，将core文件生成功能修改为默认启用，从而，对于一些进程异常问题，无需复现，也能够有效地获取相应的core文件以用于定位问题；另外，对于用户通过指定的终端中断符所发送的中断命令信号，比如，SIGINT信号等，修改了其现有的响应，使SIGINT信号能够触发core文件生成，从而，能够在更多的进程异常终止的场景下有效地获取相应的core文件。

附图说明

图1为本申请的一些实施例提供的一种core文件管理方法的流程示意图；

图2为本申请的一些实施例提供的为实现上述core文件管理方法所实施的一种具体改进流程示意图；

图3为本申请的一些实施例提供的对应于图1的一种core文件管理装置的结构示意图；

图4为本申请的一些实施例提供的对应于图1的一种core文件管理设备的结构示意图。

具体实施方式

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

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

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

如背景技术中所述，可以通过特定信号触发进程终止，这是Linux操作系统和Unix操作系统中使用的信号机制。信号机制是一种处理异步事件的方案，这里的信号实质上是一种软件中断，在信号机制下，每个进程运行期间可以向自己或者其它进程发送信号，收到信号的进程可以执行相应的动作，这些动作可以称为信号的响应动作。

例如，Linux操作系统一部分信号及其产生原因、默认的响应动作如下表1所示(“终止+core”表示进程终止并在终止前生成相应的core文件)：

表1

对于后台进程而言，进程异常终止时并没有其它很好的途径记录现场信息以便后续定位问题原因，很多进程实现了在流程中添加带开关的调试信息，能够在调试开关启用的情况下记录进程中的信息，但为了运行效率起见，调试开关一般不会开启，只有在需要定位问题时才开启。

对于core文件这种调试信息，即是上一段所说的情况，core文件生成功能目前默认是不启用的，若有相应的开关来控制core文件生成功能启用与否，该开关默认关闭而不是开启，而只有在core文件生成功能启用的前提下，才能够生成core文件。则若用户未提前启用core文件生成功能，在进程异常终止想要定位问题时，需要手动启用core文件生成功能，再复现该问题，获取相应的core文件进行定位。但是，由于环境、操作和时机的关系，问题未必方便复现。另外，本申请还针对目前core文件的其他一些管理机制进行了改进，通过这些改进也能够解决相应的技术问题，之后会一一说明。

下面对本申请的方案进行详细说明。

图1为本申请的一些实施例提供的一种core文件管理方法的流程示意图。在该流程中，从设备角度而言，执行主体可以包括一个或者多个使用Linux或者Unix操作系统的计算设备，从程序角度而言，执行主体相应地可以包括运行于这些计算设备上的进程。需要说明的是，对于图1中的流程，core文件生成功能是默认启用的，而不是像现有技术那样默认不启用，如此，无需用户手动启动core文件生成功能，除非是用户手动不启动core文件生成功能，之后又想要重新启动core文件生成功能。本申请对图1中的流程的步骤的执行顺序并不做限定，步骤是否执行以及何时执行取决于该步骤中的条件的触发情况。

图1中的流程可以包括以下步骤：

S101：若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件。

在本申请的一些实施例中，终端终端符可以包括一些特定的单个按键或者组合键，用户通过操作这些键来发送中断命令信号，比如，在启动项长时间卡住不响应时，用户可以通过点击组合键发送中断命令信号，以尝试脱离改变当前卡住不响应的状态。中断命令信号比如可以包括SIGINT信号、SIGTSTP信号等，在表1中已经示出，通过组合键Ctrl+C可以发送SIGINT信号，通过组合键Ctrl+Z可以发送SIGTSTP信号。这些中断命令信号目前默认的响应动作只是终止或者停止进程，而不会生成core文件，而本申请对该响应动作进行了修改，使得接收到这些中断命令信号之后，会生成相应的core文件，从而用户能够获得定位问题的依据。

S102：若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

在本申请的一些实施例中，目前所有会触发生成core的信号同时也会终止进程。另外，在某些场景下，不支持用gdb(一种常用的调试工具)对一个正在运行的进程进行分析，比如：在线运行的系统某个进程正在处理业务，用gdb附接该进程会导致该进程暂停执行，影响业务响应速度；或者，系统剩余内存太少，无法支持运行一个gdb进程(gdb进程运行时要监管被分析的进程的所有数据，因此，其运行时需要的内存比被分析的进程还要多)。

为了解决上一段中的问题，可以通过实现一个新的信号(即步骤S102中的预定义的core文件请求信号)，当进程接收到该信号时，只生成该进程的core文件，但并不终止该进程。从而，用户可以先向需要分析的进程发送一个该信号，然后将其生成的相应的core文件导出，然后，在同样操作系统环境的设备中进行分析。这样的操作对于所需分析的进程的影响很小(响应该信号生成core文件的过程可能会暂停业务处理流程，而这个过程时间非常短，一般是毫秒级的)，用户体验较好。

通过图1的方法，将core文件生成功能修改为默认启用，从而，对于一些进程异常问题，无需复现，也能够有效地获取相应的core文件以用于定位问题；另外，对于用户通过指定的终端中断符所发送的中断命令信号，比如，SIGINT信号等，修改了其现有的响应，使SIGINT信号能够触发core文件生成，从而，能够在更多的进程异常终止的场景下有效地获取相应的core文件；不仅如此，还新定义了一种core文件请求信号，用以触发生成相应的core文件但并不终止进程，从而能够实时调试而又不妨碍进程继续工作。

基于图1的方法，本申请的一些实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

目前，进程有一个core文件大小限制值，该值默认为0，表示不产生core文件；设置为非0值则表示产生core文件，若core文件要记录的数据的长度超出了该值，则core文件被截短为该限制值，被截短的core文件中只记录了进程终止现场的部分信息，可能影响问题定位分析，但对问题定位仍有一定帮助。

为了解决上一段中的问题，在本申请的一些实施例中，可以自动地根据进程对其core文件大小限制值进行自适应设置。一种简单的方案是：将不同进程的core文件大小限制值设置为同一个值，且该值对于至少大部分进程都是够用的，比如，设置为10MB，对于少数确实不够用的进程，可以由用户手动调整。或者，也可以根据历史经验或者各进程实时运行情况，动态地为各进程设置合适的core文件大小限制值，比如，对于某个进程，若之前生成的core文件偏小，则自动地将其core文件大小限制值调大一些，这种调整过程可以迭代多次，直到找到一个合适的core文件大小限制值。

在本申请的一些实施例中，core文件生成功能启用与否可以由指定的开关控制，在这种情况下，该指定的开关默认开启，以使core文件生成功能默认启用。而现有技术中，若使用开关控制core文件生成功能启用与否，该开关是默认关闭的，给用户带来了不便。

在本申请的一些实施例中，针对SIGINT信号，对改进具体地进行说明。可以修改SIGINT信号的默认的响应动作，在操作系统启动阶段，SIGINT信号触发在进程终止前生成core文件，以便在启动项卡住时能够利用core文件分析卡住原因；在操作系统启动阶段以外的阶段，SIGINT信号默认的响应动作可以仍为终止进程，而不生成core文件。具体分析见下面两段。

在操作系统启动阶段，除了启动界面以外往往没有其它管理手段(一些远程连接手段可能尚未恢复)，用户不能自由地操作系统。如果某个启动项长时间卡住，没有继续向下执行的迹象，用户只能通过诸如Ctrl+C等组合键发送中断命令信号，以打断启动过程，才能进一步地操作系统，但是，此后该启动项对应的进程已经接收到中断命令信号并终止了，也没有生成相应的core文件，无法分析被打断的进程有什么问题。基于此，通过改进，使操作系统处于正在启动阶段时，若进程接收到SIGINT信号，则在进程终止前生成相应的core文件。从而，当用户在操作系统启动阶段通过Ctrl+C组合键中断启动过程时，被中断的进程会生成一个core文件，以便用户分析该进程卡在哪个流程。

操作系统启动完成后，对于进程卡住的情况，可以通过Telnet、安全外壳协议(Secure Shell，SSH)等远程连接手段，与系统建立一个新的连接，并通过gdb等工具分析被卡住的进程卡在何处，此时响应SIGINT信号生成core文件可以不是必要的，因此，很多场合中，用户会通过Ctrl+C组合键中断尚未执行完的进程，可能仅仅是因为不需要等待进程结束，在这种情况下，过多的core文件反而会干扰用户分析系统故障。

基于上面三段内容，对于步骤S101，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在中断命令信号所针对的进程终止之前，生成相应的core文件，具体可以包括：在操作系统启动阶段，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在中断命令信号所针对的进程终止之前，生成相应的core文件。在这种情况下，中断命令信号至少包括SIGINT信号。另外，还可以执行：在操作系统启动完成之后的阶段，若接收到用户所发送的中断命令信号，则终止中断命令信号所针对的进程，但并不生成相应的core文件。

进一步地，为了便于判断操作系统启动阶段是否完成，可以在操作系统启动过程中的最后一个启动项启动完成之后，生成相应的标志信息(比如，标记位、通知消息等)，用于判断操作系统启动是否完成。比如，在最后一个启动项之后置一个标记位，表示操作系统已启动完成，在置上该标记位前，操作系统处于启动阶段。

在本申请的一些实施例中，若生成core文件，则还可以发送相应的提示信息，以提示用户进行处理，以防止用户不能及时知晓，造成延误。比如，可以修改core文件生成流程，在生成core文件后向预先指定的用户发送一条日志或者简单网络管理协议(SimpleNetwork Management Protocol，SNMP)trap消息，用于报告core文件的生成时间、所涉及的进程名和信号等信息。

在现有技术中，core文件的名称默认为core，且生成于当前进程的工作目录下。由于进程的工作目录可切换，因此，core文件的位置不固定，不便于用户寻找；若生成在内存文件系统的目录下，则设备重启后该core文件就丢失了。而且由于命名相同，则生成于同一目录下的core文件会覆盖较早生成的同名文件，造成更早生成的core文件丢失。

为了解决上一段中的问题，在本申请的一些实施例中，可以使core文件的文件名称反映导致该core文件生成的信号和进程，且对于由同一个信号和进程导致生成的core文件只保留1个。比如，具体可以修改core文件的名称，修改的名称由其涉及的进程名、信号组成，并且可以不加时间戳，以便每个进程由于同一信号触发生成的core文件只保留一个，防止core文件太多导致存储空间被写满，另外，还可以将core文件的路径固定为非易失性存储器对应的绝对路径。如此，同一进程因同一信号触发生成的core文件保持只有1个，新生成的core文件会将旧的core文件覆盖，从而不会由于进程反复重启、反复生成core文件而大量消耗存储空间；而同一进程因不同信号触发生成的core文件可以共存，不同进程因同一信号触发生成的core文件也可以共存，因为其生成原因很可能不一样。

上面对本申请的方案进行了详细说明。更直观地，本申请的一些实施例还提供了为实现上述core文件管理方法所实施的一种具体改进流程示意图，如图2所示。其中包含了多项改进，流程中的步骤执行顺序不做限定，可以随意调整。

图2中的流程可以包括以下步骤：

S201：默认启用core文件生成功能，且将core文件大小限制值设置为至少大部分进程够用的大小。

S202：修改操作系统启动阶段中信号SIGINT的默认的响应动作为终止进程且生成core文件。

S203：新增一个core文件请求信号，其默认的响应动作为生成core文件但不终止进程。

S204：当进程生成core文件时，发送SNMP trap消息或者向日志中心发送日志对管理人员告警。

S205：修改core文件的名称，使其由进程名、信号组成，不加时间戳，以便每个进程由于同一信号触发生成的core文件只保留1个。

采用本申请的方案，能够通过在系统公共流程中添加少量修改实现对系统中所有进程的core文件管理方案进行优化，而无需针对系统中所有进程的源码进行修改，同时也仍允许各进程根据需要自定义生成core文件的时机和文件大小等，大大提升了系统的可维护性并降低了运营成本。

基于同样的思路，本申请的一些实施例还提供了上述方法对应的装置、设备和非易失性计算机存储介质。

图3为本申请的一些实施例提供的对应于图1的一种core文件管理装置的结构示意图，虚线方框表示可选的模块，core文件生成功能默认启用，所述装置包括：

第一生成模块301，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

第二生成模块302，若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

可选地，所述core文件生成功能启用与否由指定的开关控制；

所述指定的开关默认开启，以使所述core文件生成功能默认启用。

可选地，所述第一生成模块301若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件，具体包括：

所述第一生成模块301在操作系统启动阶段，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件。

可选地，所述装置还包括：

终止模块303，在操作系统启动完成之后的阶段，若接收到用户所发送的所述中断命令信号，则终止所述中断命令信号所针对的进程，但并不生成相应的core文件。

可选地，所述装置还包括：

第三生成模块304，在操作系统启动完成之后的阶段之前，在操作系统启动过程中的最后一个启动项启动完成之后，生成相应的标志信息，用于判断操作系统启动是否完成。

可选地，所述core文件的文件名称反映了导致所述core文件生成的信号和进程，且对于由同一个信号和进程导致生成的core文件只保留1个。

可选地，所述装置还包括：

提示模块305，若生成core文件，则发送相应的提示信息，以提示用户进行处理。

可选地，所述装置应用于Linux操作系统或者Unix操作系统；所述中断命令信号包括SIGINT信号。

图4为本申请的一些实施例提供的对应于图1的一种core文件管理设备的结构示意图，core文件生成功能默认启用，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

本申请的一些实施例提供的对应于图1的一种core文件管理非易失性计算机存储介质，存储有计算机可执行指令，core文件生成功能默认启用，所述计算机可执行指令设置为：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请实施例提供的装置、设备和介质与方法是一一对应的，因此，装置、设备和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述装置、设备和介质的有益技术效果。

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

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

Claims (18)

1.一种core文件管理方法，其特征在于，core文件生成功能默认启用，所述方法包括：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

2.根据权利要求1所述的方法，其特征在于，所述core文件生成功能启用与否由指定的开关控制；

所述指定的开关默认开启，以使所述core文件生成功能默认启用。

3.根据权利要求1所述的方法，其特征在于，所述若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件，具体包括：

在操作系统启动阶段，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件。

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

在操作系统启动完成之后的阶段，若接收到用户所发送的所述中断命令信号，则终止所述中断命令信号所针对的进程，但并不生成相应的core文件。

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

在操作系统启动过程中的最后一个启动项启动完成之后，生成相应的标志信息，用于判断操作系统启动是否完成，以确定操作系统启动完成之后的阶段。

6.根据权利要求1所述的方法，其特征在于，所述core文件的文件名称反映了导致所述core文件生成的信号和进程，且对于由同一个信号和进程导致生成的core文件只保留1个。

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

若生成core文件，则发送相应的提示信息，以提示用户进行处理。

8.根据权利要求1～7任一项所述的方法，其特征在于，所述方法应用于Linux操作系统或者Unix操作系统；所述中断命令信号包括SIGINT信号。

9.一种core文件管理装置，其特征在于，core文件生成功能默认启用，所述装置包括：

第一生成模块，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

第二生成模块，若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

10.根据权利要求9所述的装置，其特征在于，所述core文件生成功能启用与否由指定的开关控制；

所述指定的开关默认开启，以使所述core文件生成功能默认启用。

11.根据权利要求9所述的装置，其特征在于，所述第一生成模块若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件，具体包括：

所述第一生成模块在操作系统启动阶段，若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件。

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

终止模块，在操作系统启动完成之后的阶段，若接收到用户所发送的所述中断命令信号，则终止所述中断命令信号所针对的进程，但并不生成相应的core文件。

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

第三生成模块，在操作系统启动完成之后的阶段之前，在操作系统启动过程中的最后一个启动项启动完成之后，生成相应的标志信息，用于判断操作系统启动是否完成。

14.根据权利要求9所述的装置，其特征在于，所述core文件的文件名称反映了导致所述core文件生成的信号和进程，且对于由同一个信号和进程导致生成的core文件只保留1个。

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

提示模块，若生成core文件，则发送相应的提示信息，以提示用户进行处理。

16.根据权利要求9～15任一项所述的装置，其特征在于，所述装置应用于Linux操作系统或者Unix操作系统；所述中断命令信号包括SIGINT信号。

17.一种core文件管理设备，其特征在于，core文件生成功能默认启用，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。

18.一种core文件管理非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，core文件生成功能默认启用，所述计算机可执行指令设置为：

若接收到用户通过指定的终端中断符所发送的中断命令信号，则在所述中断命令信号所针对的进程终止之前，生成相应的core文件；

若进程接收到预定义的core文件请求信号，则生成相应的core文件但并不终止所述进程。