Method, device and storage medium for starting management and control

Abstract

The application provides a starting control method, device, equipment and storage medium. The starting control method comprises the following steps: in response to a starting control request for a target system, loading a kernel monitoring module in a first starting stage of an initialization process corresponding to the target system, and setting a timeout timer in the kernel monitoring module; determining a second starting state of a second starting stage of the initialization process in the target system according to a timer running state of the timeout timer, wherein the timer running state is a running state representing whether the timeout timer is canceled by a timeout cancel instruction preset in the second starting stage within a preset timeout period; and performing starting control on the target system according to the second starting state to obtain a starting control result. The application significantly enhances the abnormal processing capability and self-diagnostic capability of the system in the initialization stage.

Description

Technical Field

[0001] This application relates to the field of computer technology, and specifically to a boot control method, apparatus, device, and storage medium. Background Technology

[0002] Currently, with the widespread adoption of smart terminal devices, an increasing number of products such as televisions, set-top boxes, and smart projectors are running on smart operating systems like Android. The startup process of a smart operating system typically includes multiple stages, such as boot loading, kernel initialization, the initialization (init) process, the zygote process, system services, and desktop startup. Among these, the initialization process, as the first user-space process, bears the critical responsibility of system initialization and service startup. In actual use, the system may freeze or repeatedly restart abnormally at some stage of the initialization process, preventing the device from entering the desktop normally and rendering the user unable to perform any interactive operations. Currently, smart operating systems lack effective monitoring methods for the initialization process startup stage, making it extremely difficult to locate problems when the system startup is abnormal. Summary of the Invention

[0003] This application provides a startup control method, apparatus, device, and storage medium, aiming to solve the technical problem in the prior art that it is difficult to locate abnormalities in the initialization process when the terminal system starts up.

[0004] On one hand, embodiments of this application provide a startup control method, which includes the following steps: In response to the boot control request for the target system, the kernel monitoring module is loaded in the first boot phase of the initialization process of the target system, and a timeout timer is set in the kernel monitoring module; The second startup state of the second startup phase of the initialization process in the target system is determined based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within the preset timeout period; The target system is controlled for startup based on the second startup state to obtain the startup control result.

[0005] In one possible implementation of this application, determining the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer includes: Configure a timeout cancellation instruction at the target time node of the second startup phase of the target system, and determine the timer running state of the timeout timer based on the timeout cancellation instruction; If the timer is in a timed running state, then the second startup state of the second startup phase in the target system is determined to be an abnormal startup state. If the timer is in a timer cancellation state, then the second startup state of the second startup phase in the target system is determined to be a normal startup state.

[0006] In one possible implementation of this application, the step of performing startup control on the target system according to the second startup state to obtain a startup control result includes: If the second startup state is an abnormal startup state, then the first startup control is performed on the first startup stage of the target system to obtain the first control result; If the second startup state is a normal startup state, then a startup detection is performed on the second startup stage of the target system to obtain the startup detection result; The target system is subjected to a second startup control based on the startup detection results, and a second control result is obtained.

[0007] In one possible implementation of this application, the step of performing first startup control on the first startup phase of the target system to obtain a first control result includes: The first abnormal information of the target system during the first startup phase is recorded using a log collection script to obtain the first abnormal log corresponding to the target system. The first abnormal log is stored in the target storage area, and the timeout timer is driven to execute a system restart event on the target system to obtain a first control result. The target storage area is used to respond to the storage scan event triggered by the preset reporting process to upload the first abnormal log.

[0008] In one possible implementation of this application, the step of performing second startup control on the target system according to the startup detection result to obtain a second control result includes: The startup sub-stages of the second startup phase are recorded using preset monitoring nodes to obtain the process timestamps of each startup sub-stage in the second startup phase; The service status attributes of the system incubation process in the target system are collected using the status monitoring timer corresponding to the second startup phase. The target system is subjected to a second startup control based on the service status attributes and / or the process timestamp, resulting in a second control result.

[0009] In one possible implementation of this application, the step of performing a second startup control on the target system based on the service status attribute and the process timestamp to obtain a second control result includes: Based on the process timestamp and the preset time consumption threshold, the abnormal sub-stage in the second startup phase is located, and the abnormal sub-stage is controlled to obtain the second control result. And / or, if the service status attribute is a process restart attribute, then the target system is subjected to a second startup control based on the process restart attribute and a preset time interval, to obtain a second control result.

[0010] In one possible implementation of this application, the step of performing a second startup control on the target system based on the process restart attribute and a preset timeout to obtain a second control result includes: The number of process restarts of the system incubation process is collected within a preset time interval corresponding to the status monitoring timer; If the number of process restarts is greater than or equal to the preset restart threshold or the service status attribute is not updated to the process running attribute within the preset time interval, the log collection script is used to record the stage startup information of the current sub-stage to obtain the second abnormal log. The second anomaly log is stored in the target storage area, and the target system is subjected to system recovery processing to obtain the second control result.

[0011] On the other hand, this application provides a startup control device, the startup control device comprising: The startup monitoring module is configured to respond to startup control requests for the target system, load the kernel monitoring module in the first startup phase of the corresponding initialization process of the target system, and set a timeout timer in the kernel monitoring module. The startup identification module is configured to determine the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within a preset timeout period; The startup control module is configured to perform startup control on the target system according to the second startup state, and obtain the startup control result.

[0012] On the other hand, this application also provides a startup control device, the startup control device comprising: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the steps of the startup control method.

[0013] On the other hand, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to execute the steps in the startup control method.

[0014] In this application, by responding to startup control requests for the target system, a kernel monitoring module is loaded and a timeout timer is set during the first startup phase of the target system. The running status of this timeout timer is used to determine whether the second startup phase has started normally, thus achieving early intervention monitoring of the system initialization process. Furthermore, since the cancellation of the timeout timer depends on the execution of a preset timeout cancellation instruction in the second startup phase, and this timeout cancellation instruction is configured in the startup configuration file of the second startup phase, the timer is only cancelled when the second startup phase actually reaches the corresponding time node and successfully executes the instruction. This "cancellation only upon successful execution" logic ensures high reliability of the monitoring results. In addition, categorized control is implemented based on the second startup state, with different control strategies applied to abnormal and normal startup states. This allows for timely log collection and system recovery when anomalies occur, and also enables in-depth monitoring of the running status of subsequent startup sub-stages during normal startup, forming a hierarchical startup control system that significantly enhances the system's anomaly handling and self-diagnostic capabilities during the initialization phase. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram illustrating a scenario for initiating the control method according to an embodiment of this application; Figure 2 This is a flowchart illustrating one embodiment of the control and management method described in this application. Figure 3 A flowchart illustrating an embodiment of the startup control method provided in this application for performing second startup control; Figure 4 A flowchart illustrating yet another embodiment of the startup control method provided in this application for performing second startup control; Figure 5 A schematic diagram of the structure of one embodiment of the startup control device provided in this application; Figure 6 This is a schematic diagram of one embodiment of the startup control device provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0019] In this application, the term "exemplary" is used to mean "serving as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0020] Currently, with the widespread adoption of smart terminal devices, an increasing number of products such as televisions, set-top boxes, and smart projectors are running on smart operating systems like Android. The startup process of a smart operating system typically includes multiple stages, such as boot loading, kernel initialization, the initialization (init) process, the zygote process, system services, and desktop startup. Among these, the initialization process, as the first user-space process, bears the critical responsibility of system initialization and service startup. In actual use, the system may freeze or repeatedly restart abnormally at some stage of the initialization process, preventing the device from entering the desktop normally and rendering the user unable to perform any interactive operations. Currently, smart operating systems lack effective monitoring methods for the initialization process startup stage, making it extremely difficult to locate problems when the system startup is abnormal.

[0021] Based on this, this application proposes a startup control method, apparatus, device, and computer-readable storage medium to solve the technical problem in the prior art of difficulty in abnormally locating the initialization process during the startup of a terminal system.

[0022] The startup control method in this embodiment of the invention is applied to a startup control device, which is set in a startup control equipment. The startup control device is provided with one or more processors, a memory, and one or more applications, wherein one or more applications are stored in the memory and configured to be executed by the processor to implement the startup control method. The startup control equipment can be a smart IoT terminal or other smart terminals that are communicatively connected to the IoT terminal, such as mobile phones, tablets, network devices, smart gateways, and smart computers.

[0023] like Figure 1 As shown, Figure 1 This is a schematic diagram of a scenario for the startup control method in an embodiment of this application. The startup control scenario in this embodiment includes a startup control device 100 (the startup control device 100 integrates a startup control apparatus), and the startup control device 100 has a computer-readable storage medium corresponding to the startup control method running in order to execute the steps of the startup control method.

[0024] Understandable, Figure 1 The startup control device in the startup control method scenario, or the device included in the startup control device, does not constitute a limitation on the embodiments of the present invention. That is, the number or type of startup control device included in the startup control method scenario, or the number or type of device included in each device, does not affect the overall implementation of the technical solution in the embodiments of the present invention, and can all be considered as equivalent substitutions or derivatives of the technical solutions claimed in the embodiments of the present invention.

[0025] In this embodiment of the invention, the startup control device 100 is mainly used to: respond to a startup control request for a target system, load a kernel monitoring module in the first startup phase of the initialization process corresponding to the target system, and set a timeout timer in the kernel monitoring module; The second startup state of the second startup phase of the initialization process in the target system is determined based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within the preset timeout period; The target system is controlled for startup based on the second startup state to obtain the startup control result.

[0026] The startup control device 100 in this embodiment of the invention can be an independent Internet of Things (IoT) device or a control device corresponding to an IoT device, such as a smart terminal such as a mobile phone, tablet computer, network device, server, and smart computer. It can also be a startup control network or startup control cluster composed of multiple startup control devices.

[0027] This application provides a startup control method, apparatus, device, and computer-readable storage medium, which will be described in detail below.

[0028] It will be understood by those skilled in the art that Figure 1 The application environment shown is only one application scenario related to the solution of this application and does not constitute a limitation on the application scenario of this application. Other application environments may include more than one application scenario. Figure 1 The diagram shows more or fewer startup control devices, or startup control network connections, for example... Figure 1 Only one startup control device is shown in the figure. It can be understood that the scenario of this startup control method may also include one or more startup control devices, which are not limited here. The startup control device 100 may also include a memory for storing the second startup state and other data.

[0029] It should be noted that, Figure 1 The schematic diagram of the startup control method shown is merely an example. The scenarios of the startup control method described in this embodiment of the invention are intended to more clearly illustrate the technical solutions of this embodiment and do not constitute a limitation on the technical solutions provided by this embodiment of the invention.

[0030] Based on the scenarios described above regarding startup control methods, various embodiments of the startup control method disclosed in this invention are proposed.

[0031] like Figure 2 As shown, Figure 2This is a flowchart illustrating one embodiment of the startup control method in this application. The startup control method includes the following steps 201 to 203: 201. In response to the startup control request for the target system, load the kernel monitoring module in the first startup phase of the corresponding initialization process of the target system, and set a timeout timer in the kernel monitoring module; The startup control method in this embodiment is applied to a startup control device. The type and number of startup control devices are not specifically limited. That is, the startup control device can be one or more smart terminals equipped with the target system. In a specific embodiment, the startup control device can be a smart TV or other smart terminals equipped with the target system.

[0032] Optionally, the target system refers to an embedded computing system that boots based on an operating system kernel. The target operating system can be an Android operating system or another operating system running on a smart TV, set-top box, tablet computer, or other smart terminal device. The boot process of the target system involves multiple sequentially executed stages, with strict order and dependencies between these stages. It should be noted that although the embodiments of this application primarily use the Android system as an example, the technical solutions of this application are not limited to the Android system and are equally applicable to other embedded operating systems based on the Linux kernel or similar architectures.

[0033] Optionally, the initialization process is the first user-space process executed after the operating system kernel starts. Its execution is divided into a first startup stage and a second startup stage. The first startup stage is mainly responsible for basic environment setup work such as mounting necessary file systems and creating device nodes. The second startup stage, based on the first startup stage, completes more complex initialization tasks such as starting system services and setting attributes by executing various commands and services defined in the startup configuration file (such as init.rc). In the embodiments of this application, the boundary between the first startup stage and the second startup stage is marked by the start of execution of the startup configuration file.

[0034] Optionally, a kernel monitoring module refers to a monitoring component implemented as a loadable kernel module that runs in the operating system kernel space. This module is loaded into the kernel during the first boot phase of the target system and has the ability to access kernel-level resources (such as kernel timers, proc filesystem nodes, kernel log buffers, etc.). The use of a loadable kernel module implementation is based on the consideration that under the Generic Kernel Image (GKI) strategy, device manufacturers cannot directly modify the operating system kernel source code. However, through an independent loadable module, monitoring functions can be implemented at the kernel level without modifying the kernel source code, and it can be easily adapted to different hardware platforms and kernel versions.

[0035] Optionally, a timeout timer refers to a delayed execution mechanism created in the kernel monitoring module. Its characteristic is that it presets an expiration time (i.e., a preset timeout period) during creation. If it is not canceled externally before the expiration time, the preset callback function is automatically executed upon expiration. Optionally, in a specific embodiment, the timeout timer can be implemented using the delayed work queue mechanism provided by the Linux kernel. The delayed work queue is a commonly used delayed task scheduling method in the Linux kernel. It registers a work item in the kernel's work queue and sets an expiration time. When the expiration time arrives, the kernel's worker thread automatically executes the callback function corresponding to the work item. If, before the expiration time arrives, another execution flow calls the cancellation function to remove the work item from the queue, the callback function will not be executed. Optionally, in other embodiments, the timeout timer can also be other kernel timing mechanisms with similar characteristics (such as the high-precision timer hrtimer).

[0036] Optionally, when the target system starts up, the operating system kernel is loaded and executed by the bootloader, and then the kernel starts the initialization process. The execution of the initialization process is divided into a first boot phase and a second boot phase. In the early part of the first boot phase, the system loads the kernel monitoring module into the kernel space. The "early part" here refers to the time window after the file system is mounted in the first boot phase and before the kernel initialization task begins. The kernel monitoring module is loaded in this time window because at this time the kernel already has the basic conditions for loading loadable modules (such as the file system being mounted and the module file being readable), and can establish a monitoring mechanism before the second boot phase begins.

[0037] Optionally, after the kernel monitoring module is loaded, a timeout timer is immediately created within it, and a preset timeout period is set for this timeout timer. This preset timeout period should be greater than the maximum time required for the target system to normally progress from the first boot phase to the execution of the timeout cancellation instruction in the second boot phase. In one specific embodiment of this application, the preset timeout period is set to three minutes. This time value is selected by comprehensively considering the normal boot time of the target system (typically between tens of seconds and two minutes) and possible reasonable delays. In other embodiments, the preset timeout period can be adjusted according to the hardware performance and system configuration of the specific device; for example, it can be appropriately shortened for high-performance devices and appropriately extended for devices with more complex systems.

[0038] It should be noted that the boot control request is not an explicit external trigger signal, but rather implicitly triggered by the system boot event itself. In other words, whenever the target system executes the boot process, the loading behavior of the kernel monitoring module in the first boot phase is considered a response to the boot control request.

[0039] 202. Determine the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer; Optionally, after generating the timeout timer, the terminal also determines the second startup state corresponding to the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer.

[0040] Optionally, the timer running state is a running state that indicates whether the timeout timer is canceled by the timeout cancellation instruction preset in the second startup phase of the target system within the preset timeout period.

[0041] Optionally, the second startup state is status information that characterizes whether the second startup phase of the initialization process has been started correctly.

[0042] Optionally, the terminal pre-configures a timeout cancellation instruction at the target time node of the second startup phase of the target system, determines the timer running state of the timeout timer based on the timeout cancellation instruction, and can then accurately determine whether the second startup phase has started normally through the timer running state of the timeout timer.

[0043] Optionally, the target time node refers to the earliest execution time node in the startup configuration file of the second startup phase. For example, in a specific embodiment, the target time node corresponds to the location of the onearly-init trigger in the init.rc file of the Android system. Configuring the timeout cancellation instruction at the earliest time node of the second startup phase is to confirm that the second startup phase has started execution as early as possible, thereby shortening the response delay of exception detection. If the timeout cancellation instruction is configured at a later time node, even if the second startup phase has started normally, but a freeze occurs before reaching that node, it will be incorrectly judged as an abnormal startup state. Therefore, selecting the earliest execution node in the second startup phase as the target time node is an optimization strategy that ensures the reliability of the judgment while minimizing false positives.

[0044] Optionally, the timeout cancellation instruction is written into the command sequence corresponding to the target time node in the boot configuration file. When the second boot phase begins, the initialization process executes the commands under each trigger sequentially according to the definition in the boot configuration file. When the target time node is reached, the included timeout cancellation instruction is executed. This instruction notifies the kernel monitoring module to cancel the timeout timer by writing a cancellation signal to a specific node in the specified file system (e.g., the proc file system). Upon receiving the cancellation signal, the kernel monitoring module calls the kernel's timer cancellation function to remove the timeout timer from the work queue, preventing the callback function from being executed upon its expiration.

[0045] Optionally, if the timer is in a timed running state, then the second startup state of the second startup phase in the target system is determined to be an abnormal startup state. That is, when the timeout timer is not canceled within the preset timeout period and the callback function is automatically executed after the expiration, the timer's running state is a timed running state. In this case, it can be determined that the second startup phase failed to reach the target time node within the preset timeout period, i.e., the second startup phase failed to start normally. Possible reasons for this result include: the first startup phase got stuck at some stage, causing the system to be unable to enter the second startup phase; or although the first startup phase was completed, the second startup phase encountered an anomaly in the initial part (i.e., before the target time node). In either case, the second startup state is determined to be an abnormal startup state.

[0046] Optionally, if the timer's running state is a timed-cancellation state, then the second startup state of the second startup phase in the target system is determined to be a normal startup state. That is, when the timeout timer is successfully canceled by a timeout cancellation command before the preset timeout period expires, the timer's running state is a timed-cancellation state. At this time, it can be determined that the second startup phase has started normally and successfully executed to the target time node. The system has successfully passed the initial parts of both the first and second startup phases and can continue the subsequent startup process. Therefore, the second startup state is determined to be a normal startup state.

[0047] 203. Perform startup control on the target system according to the second startup state to obtain the startup control result.

[0048] Optionally, after determining the second startup state corresponding to the second startup phase, the terminal performs startup control on the target system based on the second startup state to obtain a startup control result. That is, based on the determined second startup state, the terminal adopts different startup control strategies to control the startup process of the target system. If the second startup state is an abnormal startup state, the control measures for the first startup phase are executed, including any one or more control measures such as collecting abnormal logs and triggering a system restart. If the second startup state is a normal startup state, more in-depth startup detection is performed on the second startup phase, including monitoring the execution status of each startup sub-stage, collecting the status attributes of key services, etc., and corresponding control processing is performed based on the detection results to obtain a startup control result.

[0049] Optionally, when the terminal determines that the second startup phase has failed to start normally, it is necessary to manage the abnormal situation in the first startup phase. The main purpose of first startup management is to collect and save as much abnormal situation information as possible in the abnormal system state, and trigger a system restart to attempt recovery.

[0050] That is, when the timeout expires and triggers the callback function, the callback function first calls the log collection script to perform log collection operations. Specifically, the callback function obtains the log data in the current kernel ring buffer through the kernel log interface. This log data contains various information output by the kernel and various driver modules during the execution of the first startup phase, including normal startup logs and error information in abnormal states. The collected log data is formatted and organized to form the first abnormal log.

[0051] Optionally, in one embodiment of this application, the log collection operation is implemented by calling the kernel's log reading interface, which can read the most recent log record from the kernel's circular buffer. In another embodiment, the kernel panic function can be called first in the callback function of the timeout timer to trigger a kernel crash dump (kdump), and the crash dump mechanism will automatically write the complete kernel memory state and log information to a preset storage location.

[0052] Optionally, the collected first anomaly log is written to a target storage area for persistent storage. In one embodiment of this application, the target storage area is a pre-allocated dedicated partition on the eMMC memory. This partition is independent of the system data partition and the system cache partition and will not be erased or overwritten during normal system operation and flashing operations. After the anomaly log is written to this dedicated partition, the anomaly log can still be saved even if a forced flashing operation is subsequently performed.

[0053] Optionally, after the log storage is complete, the timeout timer callback function continues to execute the system restart event. In one embodiment of this application, the system restart event is triggered by calling the kernel's `panic` function, which causes the system to execute an emergency restart process. In another embodiment, a hardware-level restart can also be triggered directly by calling the kernel's `emergency_restart` function. The reason for choosing the `panic` function instead of directly calling the restart function is that the `panic` function performs a series of standard kernel cleanup operations before triggering a restart, including calling the registered `panic` notification chain callback and flushing the kernel log to persistent storage, thus providing more complete information about the abnormal situation.

[0054] Optionally, in another embodiment of this application, before performing a system reboot, it can be further determined whether the current system is in a state of continuous abnormal reboots. Specifically, an abnormal reboot counter can be set during the bootloader stage, checking whether the previous boot was completed normally each time the system starts. If the previous boot failed to complete normally (for example, by detecting a flag that is only set after a normal boot), the value of the abnormal reboot counter is incremented by one. When the value of the abnormal reboot counter reaches a preset consecutive threshold (e.g., three or five times), the system no longer executes the normal boot process, but directly boots into recovery mode, where data partitions are restored. The advantage of this mechanism is that if the system gets stuck in an infinite loop of "boot-freeze-reboot-reboot-freeze again", this extreme situation can be detected by the continuous abnormal reboot counter, and the system can attempt to repair it by entering recovery mode, rather than endlessly looping reboots. After the data partition restoration is completed in recovery mode, the abnormal reboot counter is reset, and the system attempts to boot normally again. If the boot is successful, the abnormal reboot counter is cleared to zero.

[0055] Optionally, the first exception log stored in the target storage area can be uploaded at an appropriate time via a pre-defined reporting process. Specifically, when the system recovers normally during a startup (i.e., the second startup state is a normal startup state, and the subsequent startup process is also successfully completed), the pre-defined reporting process in the system will be started. This reporting process will scan the target storage area to check if there are any exception logs that have not yet been reported. If an exception log is found, the reporting process will upload it to the cloud server for developers to analyze remotely. After the reporting is completed, the reported logs in the target storage area can be marked or cleaned up to free up storage space for the next exception log. This mechanism of "local storage during exceptions and cloud reporting during normal times" ensures that even if the system is unable to connect to the network at the time of the exception, the log information will not be lost and can still be uploaded and analyzed after the system recovers.

[0056] Optionally, once the terminal determines that the second startup phase has started normally, it is necessary to perform more detailed detection and corresponding startup control on its subsequent startup process. The main contents of startup detection include: monitoring the execution status and time consumption of each startup sub-phase in the second startup phase, collecting changes in the status attributes of key system services, generating corresponding startup detection results, and performing second startup control on the target system according to the startup detection results to obtain the second control results.

[0057] In this embodiment, the startup control device, in response to startup control requests for the target system, loads the kernel monitoring module and sets a timeout timer during the first startup phase of the target system. The running status of this timeout timer is used to determine whether the second startup phase has started normally, achieving early intervention monitoring of the system initialization process. Furthermore, since the cancellation of the timeout timer depends on the execution of a preset timeout cancellation instruction in the second startup phase, and this instruction is configured in the startup configuration file for the second startup phase, the timer is only cancelled when the second startup phase actually reaches the corresponding time node and successfully executes the instruction. This "cancellation only upon successful execution" logic ensures high reliability of the monitoring results. In addition, categorized control is implemented based on the second startup state, with different control strategies for abnormal and normal startup states. This allows for timely log collection and system recovery when anomalies occur, and also enables in-depth monitoring of the running status of subsequent startup sub-stages during normal startup, forming a hierarchical startup control system that significantly enhances the system's anomaly handling and self-diagnostic capabilities during the initialization phase.

[0058] like Figure 3 As shown, Figure 3 This is a flowchart illustrating an embodiment of the startup control method provided in this application, specifically a second startup control process. Figure 3 In the illustrated embodiment, the activation control method further includes steps 301 to 303: 301. Use preset monitoring nodes to record the startup sub-stages of the second startup phase to obtain the process timestamps of each startup sub-stage in the second startup phase; 302. Collect the service status attributes of the system incubation process in the target system using the status monitoring timer corresponding to the second startup phase; 303. Perform a second startup control on the target system based on the service status attribute and / or the process timestamp to obtain a second control result.

[0059] Based on the above embodiments, after the terminal determines that the second startup phase has started normally, it needs to perform more detailed detection and corresponding startup control on its subsequent startup process. The main contents of startup detection include: monitoring the execution status and time consumption of each startup sub-phase in the second startup phase, collecting changes in the status attributes of key system services, generating corresponding startup detection results, and performing second startup control on the target system according to the startup detection results to obtain the second control result.

[0060] Optionally, the startup process of the second startup phase can be further subdivided into multiple startup sub-phases. Taking the Android system as an example, the second startup phase typically includes multiple trigger phases such as on early-init, on init, on late-init, onboot, and on zygote-start, each of which contains several specific command and service startup operations. To finely monitor the execution of each startup sub-phase, this application creates a preset monitoring node in the kernel monitoring module.

[0061] Optionally, the preset monitoring node is a node that monitors data information of the boot sub-stages through a virtual file system. This virtual file system can be the proc file system, a virtual file system provided by the Linux kernel. It exists as an interface for information exchange between kernel space and user space, allowing users to communicate with the kernel by reading and writing files in the virtual file system. In the embodiments of this application, the kernel monitoring module creates a node file named init_monitor in the virtual file system as the preset monitoring node. Simultaneously, in the boot configuration file of the second boot stage, a write command is configured for each boot sub-stage. This write command writes the identifier information of the current boot sub-stage and the current system time to the preset monitoring node. After receiving the written data, the kernel monitoring module records it in kernel memory.

[0062] Optionally, through the above mechanism, as the second startup phase progresses, the preset monitoring nodes will gradually accumulate the identification information and corresponding timestamps of each startup sub-stage, forming a complete startup timeline. Developers can read the contents of the preset monitoring nodes to intuitively understand the execution order and time consumption of each startup sub-stage in the second startup phase, thereby quickly locating startup sub-stages with abnormal time consumption.

[0063] Optionally, in another embodiment of this application, the preset monitoring node can also be implemented through the sys file system or the debugfs file system.

[0064] Optionally, while recording the timestamps of the startup sub-phases, this application also monitors the status of critical services of the target system using a status monitoring timer. The status monitoring timer is another delayed execution mechanism created in the kernel monitoring module, and its function differs from the aforementioned timeout timer: the timeout timer is used for cross-phase status determination, while the status monitoring timer is used to periodically collect service status within the second startup phase.

[0065] Optionally, in one embodiment of this application, the status monitoring timer is also implemented using a delayed work queue, but its execution mode is periodic rather than one-time execution. Specifically, the status monitoring timer executes a callback function every preset collection interval (e.g., 10 seconds), and reads the service status attributes of the target system in the callback function. Service status attributes refer to attribute values ​​in the target system used to identify the current running status of critical system services. The service status attribute can be the value of the system attribute `init.svc.zygote` in the target system, which reflects the current running status of the system incubation process and can be used for judgment. Optionally, in a specific embodiment, the system incubation process is the Zygote process, indicating whether the critical process of the target system has started normally.

[0066] Optionally, the system incubation process is a crucial system process in the target system. It is the parent process of all application processes and is responsible for forking all application processes in the system. The successful startup of the system incubation process is an important indicator of the target system's successful startup. Therefore, by monitoring the service status attributes of the system incubation process, it is possible to accurately determine whether the core startup tasks of the second startup phase have been completed.

[0067] The status monitoring timer retrieves service status attributes by reading the value of the `init.svc.zygote` property. When this property value is "running," it indicates that the Zygote process has successfully started and is in a running state; when this property value is "restarted," it indicates that the system incubation process is restarting; and when this property value is "stopped," it indicates that the system incubation process has stopped.

[0068] Optionally, the terminal may implement corresponding control measures for the second startup phase based on the collected service status attributes and / or the recorded process timestamps.

[0069] Optionally, in one specific embodiment, the terminal can perform time-consuming anomaly detection on the startup sub-process based on the process timestamp. The process timestamps of each startup sub-stage are compared with a preset time consumption threshold. If the time consumption of a startup sub-stage exceeds the preset time consumption threshold, it is marked as an abnormal sub-stage, and the abnormal sub-stage is controlled. Control measures may include recording abnormal information, triggering alarm notifications, etc. The preset time consumption threshold can be set based on the normal time consumption statistics of each startup sub-stage, for example, taking two or three times the normal time consumption as the threshold.

[0070] That is, the terminal system compares the process timestamps of each startup sub-stage in the second startup phase with preset time consumption thresholds. The preset time consumption thresholds can be a uniform time value, or different thresholds can be set for different startup sub-stages. When the actual time consumption of a startup sub-stage exceeds its corresponding preset time consumption threshold, the startup sub-stage is identified as an abnormal sub-stage.

[0071] In one embodiment of this application, the system records the identification information, actual time consumption, and corresponding preset time consumption threshold of the abnormal sub-stage for management. This information is then saved to the target storage area during subsequent log collection operations. In another embodiment, the system can also output alarm information for the abnormal sub-stage through a kernel log output interface (such as printk) to leave an exception record in the kernel log. Timestamp-based abnormal sub-stage localization helps developers identify performance bottlenecks during startup. For example, if the time consumption of a service startup sub-stage significantly exceeds the normal level, it may indicate blocking operations or resource contention during the service initialization process. Through continuous monitoring and statistical analysis of these abnormal sub-stages, developers can perform targeted startup performance optimization.

[0072] Optionally, the terminal can detect process restarts based on service status attributes. If the service status attribute is "process restart," it indicates that the system incubation process is undergoing a restart. At this point, the number of restarts of the system incubation process within a preset time period is further counted. If the number of restarts exceeds a preset restart threshold, a serious system anomaly is determined, triggering log collection and system recovery processing.

[0073] In other words, if the service status attribute is a process restart attribute (i.e., the value of init.svc.zygote changes to "restarting"), then a second startup control is performed on the target system in conjunction with a preset timeout period. Specifically, within the preset timeout window of the status monitoring timer, the number of times the service status attribute changes to the process restart attribute is counted to determine whether the system's incubation process has fallen into an abnormal state of frequent restarts.

[0074] Frequent restarts of the system incubation process are a particularly difficult-to-detect anomaly. In this scenario, although the system incubation process can start, it crashes shortly after startup for some reason and is automatically restarted by the system, creating a cycle of "startup-crash-restart-restart-crash again." From the user's perspective, the device may appear to be stuck on the boot animation screen for an extended period, unable to access the desktop. Relying solely on timeout mechanisms is insufficient to detect this anomaly because the system incubation process has indeed started (its attribute value has changed to "running"), and the timeout condition may not be triggered. Therefore, by additionally monitoring the process restart attribute and combining it with restart count statistics, the shortcomings of simple timeout detection are compensated for.

[0075] In one embodiment of this application, the two control measures described above can be enabled simultaneously and executed in parallel. If either measure detects an anomaly, the corresponding control operation is triggered. In another embodiment, only one control path can be enabled based on actual needs. For example, in products with high startup performance requirements, both paths can be enabled simultaneously to comprehensively monitor startup time and service stability; in products with higher stability requirements but relatively less stringent performance requirements, only the second control path can be enabled to focus on service restart anomalies.

[0076] In this embodiment, the startup control device and the corresponding target system utilize preset monitoring nodes to record the startup sub-stages of the second startup phase, obtaining the process timestamps of each startup sub-stage in the second startup phase; the service status attributes of the system incubation processes in the target system are collected using the status monitoring timer corresponding to the second startup phase; and the target system is subjected to second startup control based on the service status attributes and / or the process timestamps to obtain the second control result. This achieves real-time monitoring of the running status of the system's core processes, enabling timely detection of abnormal situations such as service startup failures or frequent restarts. The combined use of process timestamps and service status attributes provides comprehensive monitoring coverage of the second startup phase from both time and status dimensions, significantly improving the accuracy and comprehensiveness of anomaly detection.

[0077] like Figure 4 As shown, Figure 4 This is a flowchart illustrating yet another embodiment of the startup control method provided in this application, which performs a second startup control. Figure 4 In the illustrated embodiment, the startup control method includes steps 401 to 403: 401. Collect the number of process restarts of the system incubation process within the preset time interval corresponding to the status monitoring timer; 402. If the number of process restarts is greater than or equal to the preset restart threshold or the service status attribute is not updated to the process running attribute within the preset time interval, the stage startup information of the current sub-stage is recorded using the log collection script to obtain the second abnormal log. 403. Store the second abnormal log in the target storage area, perform system recovery processing on the target system, and obtain the second control result.

[0078] Based on the above embodiments, the terminal's status monitoring timer runs continuously within its preset time window. Each time a callback is executed, it checks the current value of the service status attribute corresponding to the system incubation process. If the current value is the process restart attribute, the process restart count is incremented by one. In this way, the number of times the system incubation process has restarted within the preset time period can be counted.

[0079] Optionally, in one specific embodiment of this application, the preset timeout period is four minutes, and the data collection interval is ten seconds. Within the four-minute time window, the status monitoring timer executes a maximum of twenty-four data collections. During each data collection, if the service status attribute value is a process restart attribute, the process restart count is incremented by one. It should be noted that, to avoid duplicate counting of the same restart event, a deduplication flag can be set after detecting that the attribute value has changed to the process restart attribute. This flag is not cleared until the attribute value changes to another status, thus ensuring that each restart is counted only once.

[0080] Optionally, if the number of process restarts reaches or exceeds a preset restart threshold (e.g., four times), it is determined that the system incubation process has entered an abnormal state of frequent restarts; or, if the service status attribute does not change to the process running attribute throughout the entire preset time period, it indicates that the system incubation process failed to start successfully within the preset time. If either of the above conditions is met, the target system corresponding to the terminal determines that a serious anomaly has occurred in the second startup phase.

[0081] Optionally, when the target system corresponding to the terminal determines that a serious anomaly has occurred in the second startup phase, the system collects the current phase startup information through a log collection script. This phase startup information includes, but is not limited to: the identifier of the current startup sub-phase, process timestamps for each startup sub-phase, the history of changes in service status attributes, the number of process restarts, and system uptime. This information is formatted and organized to form the second anomaly log.

[0082] Optionally, in one embodiment of this application, the log collection script transmits the collection command from kernel space to user space via socket communication. Specifically, the kernel monitoring module sends a log collection notification to the daemon process in user space. After receiving the notification, the daemon process starts the log collection service, which executes a preset log collection script to collect log information at the target system level, including logcat logs, system attribute snapshots, process status information, etc. This method of triggering user space log collection via socket communication allows the scope of log collection to extend beyond the kernel level to encompass rich information from user space, providing a more comprehensive basis for problem analysis.

[0083] In another embodiment, log collection can also be performed directly in kernel space, whereby the kernel monitoring module directly calls kernel interfaces to obtain kernel logs and related status information. The advantages of this approach are faster execution speed and independence from user-space service availability; however, the collection scope is limited to kernel-level information.

[0084] Optionally, the second abnormal log collected by the log collection script is written to the target storage area for persistent storage. Its storage mechanism is the same as that of the first abnormal log, and both are saved to a dedicated partition independently allocated on the eMMC storage.

[0085] Optionally, after the log storage is complete, the system performs recovery processing. In one embodiment of this application, system recovery processing is achieved by triggering a system restart, after which the system re-enters the complete startup process. If the system still experiences the same anomaly after restarting, the aforementioned abnormal restart counter will continue to accumulate. When the number of consecutive abnormal restarts reaches a preset consecutive threshold, the system will enter recovery mode to perform data partition recovery operations.

[0086] In another embodiment, system recovery may go beyond a simple reboot, and may also include: attempting to stop the service causing the anomaly, clearing potentially corrupted cached data, and rolling back to a previously known working configuration. These more granular recovery strategies can be selected based on the specific anomaly type and product requirements.

[0087] In this embodiment, the startup control device establishes a quantifiable process stability assessment mechanism by counting the number of process restarts within a preset time window and comparing it with a preset restart threshold. This allows the system to objectively determine whether critical processes have fallen into an abnormal state of frequent restarts. Simultaneously, "service status attributes not being updated to running attributes within a preset time" is used as another anomaly detection condition, ensuring that even in scenarios where no restart occurs but the process fails to start, the system can promptly detect anomalies and take control measures. By transmitting log collection commands from kernel space to user space via socket communication, the scope of anomaly log collection is expanded from the kernel level to the user space level, significantly improving the richness and completeness of log information. Finally, the combination of persistent storage of anomaly logs and system recovery processing ensures reliable preservation of problem situation information while enabling the system to attempt recovery in a timely manner, addressing both problem diagnosis and user experience needs.

[0088] To better implement the startup control method in the embodiments of this application, a startup control device is also provided in the embodiments of this application, such as... Figure 5 As shown, Figure 5 This is a schematic diagram of one embodiment of the startup control device provided in this application. Specifically, the startup control device 500 includes: The startup monitoring module is configured to respond to startup control requests for the target system, load the kernel monitoring module in the first startup phase of the corresponding initialization process of the target system, and set a timeout timer in the kernel monitoring module. The startup identification module is configured to determine the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within a preset timeout period; The startup control module is configured to perform startup control on the target system according to the second startup state, and obtain the startup control result.

[0089] In one possible implementation of this embodiment, the startup control device determines the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer, including: Configure a timeout cancellation instruction at the target time node of the second startup phase of the target system, and determine the timer running state of the timeout timer based on the timeout cancellation instruction; If the timer is in a timed running state, then the second startup state of the second startup phase in the target system is determined to be an abnormal startup state. If the timer is in a timer cancellation state, then the second startup state of the second startup phase in the target system is determined to be a normal startup state.

[0090] In one possible implementation of this embodiment, the startup control device performs startup control on the target system according to the second startup state to obtain a startup control result, including: If the second startup state is an abnormal startup state, then the first startup control is performed on the first startup stage of the target system to obtain the first control result; If the second startup state is a normal startup state, then a startup detection is performed on the second startup stage of the target system to obtain the startup detection result; The target system is subjected to a second startup control based on the startup detection results, and a second control result is obtained.

[0091] In one possible implementation of this embodiment, the startup control device performs first startup control on the first startup phase of the target system to obtain a first control result, including: The first abnormal information of the target system during the first startup phase is recorded using a log collection script to obtain the first abnormal log corresponding to the target system. The first abnormal log is stored in the target storage area, and the timeout timer is driven to execute a system restart event on the target system to obtain a first control result. The target storage area is used to respond to the storage scan event triggered by the preset reporting process to upload the first abnormal log.

[0092] In one possible implementation of this embodiment, the startup control device performs a second startup control on the target system according to the startup detection result, and obtains a second control result, including: The startup sub-stages of the second startup phase are recorded using preset monitoring nodes to obtain the process timestamps of each startup sub-stage in the second startup phase; The service status attributes of the system incubation process in the target system are collected using the status monitoring timer corresponding to the second startup phase. The target system is subjected to a second startup control based on the service status attributes and / or the process timestamp, resulting in a second control result.

[0093] In one possible implementation of this embodiment, the startup control device performs second startup control on the target system based on the service status attribute and the process timestamp to obtain a second control result, including: Based on the process timestamp and the preset time consumption threshold, the abnormal sub-stage in the second startup phase is located, and the abnormal sub-stage is controlled to obtain the second control result. And / or, if the service status attribute is a process restart attribute, then the target system is subjected to a second startup control based on the process restart attribute and a preset time interval, to obtain a second control result.

[0094] In one possible implementation of this embodiment, the startup control device performs a second startup control on the target system based on the process restart attribute and a preset timeout, obtaining a second control result, including: The number of process restarts of the system incubation process is collected within a preset time interval corresponding to the status monitoring timer; If the number of process restarts is greater than or equal to the preset restart threshold or the service status attribute is not updated to the process running attribute within the preset time interval, the log collection script is used to record the stage startup information of the current sub-stage to obtain the second abnormal log. The second anomaly log is stored in the target storage area, and the target system is subjected to system recovery processing to obtain the second control result.

[0095] In this embodiment, the startup control device, in response to startup control requests for the target system, loads the kernel monitoring module and sets a timeout timer during the first startup phase of the target system. The running status of this timeout timer is used to determine whether the second startup phase has started normally, achieving early intervention monitoring of the system initialization process. Furthermore, since the cancellation of the timeout timer depends on the execution of a preset timeout cancellation instruction in the second startup phase, and this timeout cancellation instruction is configured in the startup configuration file of the second startup phase, the timer is only cancelled when the second startup phase actually reaches the corresponding time node and successfully executes the instruction. This "cancellation only upon successful execution" logic ensures high reliability of the monitoring results. In addition, categorized control is implemented based on the second startup state, with different control strategies for abnormal and normal startup states. This allows for timely log collection and system recovery when an anomaly occurs, and also enables in-depth monitoring of the running status of subsequent startup sub-stages during normal startup, forming a hierarchical startup control system that significantly enhances the system's anomaly handling and self-diagnostic capabilities during the initialization phase.

[0096] This invention also provides a startup control device, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of one embodiment of the startup control device provided in this application.

[0097] The startup control device integrates any one of the startup control devices provided in the embodiments of the present invention, and the startup control device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor in the steps of the startup control method described in any of the above-described startup control method embodiments.

[0098] Specifically, the start-up control device may include components such as a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, and an input unit 604. Those skilled in the art will understand that... Figure 6 The startup control device structure shown does not constitute a limitation on the startup control device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 601 is the control center of the boot control device. It connects various parts of the boot control device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, it performs various functions and processes data, thereby providing overall monitoring of the boot control device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0099] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and performs boot control by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of the boot control device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0100] The start-up control equipment also includes a power supply 603 that supplies power to various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0101] The start-up control device may also include an input unit 604, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0102] Although not shown, the startup control device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the startup control device loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602 to realize various functions, as follows: In response to the boot control request for the target system, the kernel monitoring module is loaded in the first boot phase of the initialization process of the target system, and a timeout timer is set in the kernel monitoring module; The second startup state of the second startup phase of the initialization process in the target system is determined based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within the preset timeout period; The target system is controlled for startup based on the second startup state to obtain the startup control result.

[0103] Therefore, embodiments of the present invention provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk, or an optical disk, etc. A computer program is stored thereon, which is loaded by a processor to execute the steps in any of the boot control methods provided in the embodiments of the present invention. For example, the computer program loaded by the processor may execute the following steps: In response to the boot control request for the target system, the kernel monitoring module is loaded in the first boot phase of the initialization process of the target system, and a timeout timer is set in the kernel monitoring module; The second startup state of the second startup phase of the initialization process in the target system is determined based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within the preset timeout period; The target system is controlled for startup based on the second startup state to obtain the startup control result.

[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0105] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0106] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0107] The above provides a detailed description of a startup control method provided by the embodiments of this application. Specific embodiments have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A startup control method, characterized in that, The startup control method includes: In response to the boot control request for the target system, the kernel monitoring module is loaded in the first boot phase of the initialization process of the target system, and a timeout timer is set in the kernel monitoring module; The second startup state of the second startup phase of the initialization process in the target system is determined based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within the preset timeout period; The target system is controlled for startup based on the second startup state to obtain the startup control result.

2. The startup control method according to claim 1, characterized in that, The step of determining the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer includes: Configure a timeout cancellation instruction at the target time node of the second startup phase of the target system, and determine the timer running state of the timeout timer based on the timeout cancellation instruction; If the timer is in a timed running state, then the second startup state of the second startup phase in the target system is determined to be an abnormal startup state. If the timer is in a timer cancellation state, then the second startup state of the second startup phase in the target system is determined to be a normal startup state.

3. The startup control method according to claim 1, characterized in that, The step of performing startup control on the target system according to the second startup state to obtain startup control results includes: If the second startup state is an abnormal startup state, then the first startup control is performed on the first startup stage of the target system to obtain the first control result; If the second startup state is a normal startup state, then a startup detection is performed on the second startup stage of the target system to obtain the startup detection result; The target system is subjected to a second startup control based on the startup detection results, and a second control result is obtained.

4. The startup control method according to claim 3, characterized in that, The first startup control of the first startup phase in the target system, to obtain the first control result, includes: The first abnormal information of the target system during the first startup phase is recorded using a log collection script to obtain the first abnormal log corresponding to the target system. The first abnormal log is stored in the target storage area, and the timeout timer is driven to execute a system restart event on the target system to obtain a first control result. The target storage area is used to respond to the storage scan event triggered by the preset reporting process to upload the first abnormal log.

5. The startup control method according to claim 3, characterized in that, The second startup control of the target system based on the startup detection result, to obtain the second control result, includes: The startup sub-stages of the second startup phase are recorded using preset monitoring nodes to obtain the process timestamps of each startup sub-stage in the second startup phase; The service status attributes of the system incubation process in the target system are collected using the status monitoring timer corresponding to the second startup phase. The target system is subjected to a second startup control based on the service status attributes and / or the process timestamp, resulting in a second control result.

6. The startup control method according to claim 5, characterized in that, The second startup control of the target system based on the service status attribute and the process timestamp, to obtain the second control result, includes: Based on the process timestamp and the preset time consumption threshold, the abnormal sub-stage in the second startup phase is located, and the abnormal sub-stage is controlled to obtain the second control result. And / or, if the service status attribute is a process restart attribute, then the target system is subjected to a second startup control based on the process restart attribute and a preset time interval, to obtain a second control result.

7. The startup control method according to claim 6, characterized in that, The second startup control of the target system based on the process restart attributes and preset time intervals, to obtain a second control result, includes: The number of process restarts of the system incubation process is collected within a preset time interval corresponding to the status monitoring timer; If the number of process restarts is greater than or equal to the preset restart threshold or the service status attribute is not updated to the process running attribute within the preset time interval, the log collection script is used to record the stage startup information of the current sub-stage to obtain the second abnormal log. The second anomaly log is stored in the target storage area, and the target system is subjected to system recovery processing to obtain the second control result.

8. A start-up control device, characterized in that, The start-up control device includes: The startup monitoring module is configured to respond to startup control requests for the target system, load the kernel monitoring module in the first startup phase of the corresponding initialization process of the target system, and set a timeout timer in the kernel monitoring module. The startup identification module is configured to determine the second startup state of the second startup phase of the initialization process in the target system based on the timer running state corresponding to the timeout timer, wherein the timer running state is a running state that characterizes whether the timeout timer is canceled by the timeout cancellation instruction preset by the second startup phase in the target system within a preset timeout period; The startup control module is configured to perform startup control on the target system according to the second startup state, and obtain the startup control result.

9. A start-up control device, characterized in that, The start-up control device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the steps of the startup control method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to execute the steps of the startup control method according to any one of claims 1 to 7.

Images