A daemon restart method and device, electronic equipment, and storage medium

Abstract

The embodiment of the present application provides a daemon restart method, which comprises the following steps: starting a pre-created unit file after starting a daemon; obtaining historical failure data of a recent period from a log at a preset period; inputting the historical failure data into a deep learning model and obtaining a recommended restart interval and a recommended retry number output by the deep learning model; dynamically adjusting a preset restart strategy based on the recommended restart interval and the recommended retry number output by the deep learning model to obtain an updated restart strategy; monitoring a running state of the daemon by using the unit file; and restarting the daemon according to the updated restart strategy if the daemon is abnormal. The embodiment of the present application improves the stability, automation degree and management efficiency of the system, reduces the cost and workload of system maintenance, improves the experience and satisfaction of users, and enhances the competitiveness and market value of the system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system management and automation, and particularly relates to a daemon restart method and device, an electronic device and a storage medium. BACKGROUND

[0002] With the popularization of informatization in various fields of society, servers play an increasingly important role as key devices for data processing and storage. In this process, OpenBMC, as an open-source management controller based on the Linux system, has been widely used, especially in devices such as servers. Its main responsibilities include monitoring hardware status, implementing remote management and other functions. In OpenBMC, Dbus serves as an important communication mechanism and plays a crucial role in the operation of the system. However, once the Dbus daemon fails, it may cause system dysfunction or even become unusable, so it is particularly important to detect and recover the failure of the Dbus daemon in a timely manner.

[0003] In the current OpenBMC, the Dbus daemon belongs to a relatively low-level service process, and lacks an automatic monitoring and restarting mechanism. After a failure occurs, manual restart is required to restore its operation. However, this approach is wasteful in terms of time and space. SUMMARY

[0004] In view of the above problems, the present application provides a daemon restart method and device, an electronic device and a storage medium.

[0005] In the first aspect of the present application, a daemon restart method is first provided, applied to an embedded system, characterized in that the method comprises:

[0006] After starting the daemon, a pre-created unit file is started, and the unit file is provided with a monitoring script for monitoring the running state of the daemon;

[0007] The preset period is adopted to obtain historical failure data of the recent period from the log;

[0008] The historical failure data is input into a deep learning model, and a recommended restart interval and a recommended retry number output by the deep learning model are obtained. Based on the recommended restart interval and the recommended retry number output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy;

[0009] The unit file is used to monitor the running state of the daemon, and if the daemon appears abnormal, the embedded system restarts the daemon according to the updated restart strategy.

[0010] Optionally, the pre-created unit file for startup includes:

[0011] Create the unit file in the preset directory;

[0012] The unit file can be started by obtaining the user's input command to start the service, or by configuring an automatic startup function.

[0013] Optionally, the preset period is the period during which the daemon process restarts;

[0014] Using a preset period, retrieve historical fault data from the logs for the most recent time period, including:

[0015] Based on the restart cycle of the daemon process, retrieve historical fault data of the daemon process restart process in the most recent period from the log.

[0016] Optionally, the restart strategy includes a restart interval value, a retry count value, a maximum number of retries, a maximum number of restarts, and a retry waiting time.

[0017] If the daemon process encounters an error, the embedded system restarts the daemon process according to the updated restart strategy, including:

[0018] Attempt to restart according to the restart policy and obtain the first historical fault data during the restart attempt;

[0019] If the restart fails, based on the first historical fault data, update the retry count, maximum retry count, and retry waiting time in the restart policy, and continue to attempt to restart according to the updated restart policy;

[0020] Repeat the restart strategy steps as described above until the restart is successful, or until the number of restart attempts reaches the maximum number of retries after the update.

[0021] If the number of restart attempts reaches the updated maximum number of retries, obtain the second historical fault data during the restart process, and update the restart interval value and the maximum number of restarts in the restart strategy based on the second historical fault data;

[0022] Restart the daemon process according to the updated restart policy;

[0023] Repeat the steps described above to attempt a restart according to the restart strategy until a successful restart is achieved, or the number of restarts reaches the maximum number of restarts after the update.

[0024] If the number of restarts reaches the maximum number of restarts after the update, stop restarting the daemon process and wait for manual intervention.

[0025] Optionally, the historical fault data is input into a deep learning model, and the recommended restart interval and recommended retry count output by the deep learning model are obtained. Based on the recommended restart interval and recommended retry count output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy, including:

[0026] Input the first historical fault data into the deep learning model to obtain the recommended retry count, recommended maximum retry count, and recommended retry waiting time output by the deep learning model.

[0027] The restart strategy is dynamically adjusted based on the recommended number of retry counts, the recommended maximum number of retry counts, and the recommended retry waiting time to obtain the updated restart strategy.

[0028] Optionally, the historical fault data is input into a deep learning model, and the recommended restart interval and recommended retry count output by the deep learning model are obtained. Based on the recommended restart interval and recommended retry count output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy, which further includes:

[0029] Input the second historical fault data into the deep learning model to obtain the recommended restart interval value and the recommended maximum number of restarts output by the deep learning model;

[0030] The restart strategy is adjusted based on the recommended restart interval and the recommended maximum number of restarts to obtain the updated restart strategy.

[0031] Optionally, the restart strategy also includes a restart interval growth coefficient;

[0032] The restart strategy is adjusted based on the recommended restart interval and the recommended maximum number of restarts to obtain an updated restart strategy, including:

[0033] Input the second historical fault data into the deep learning model to obtain the recommended restart interval growth coefficient output by the deep learning model;

[0034] Based on the recommended restart interval value and / or the recommended restart interval growth coefficient, the restart interval value and / or the restart interval growth coefficient are dynamically adjusted, and the product of the restart interval value and the restart interval growth coefficient is used as the recommended restart interval to adjust the restart strategy.

[0035] In a second aspect of the present invention, a daemon restart device is also provided, the device comprising:

[0036] The startup module is used to start a pre-created unit file after the daemon process starts. The unit file contains a monitoring script for monitoring the running status of the daemon process.

[0037] The data acquisition module is used to retrieve historical fault data for the most recent period from the logs using a preset period.

[0038] The restart strategy adjustment module is used to input the historical fault data into the deep learning model, obtain the recommended restart interval and recommended retry number output by the deep learning model, and dynamically adjust the preset restart strategy based on the recommended restart interval and recommended retry number output by the deep learning model to obtain an updated restart strategy.

[0039] The restart module is used to monitor the running status of the daemon process using the unit file. If the daemon process encounters an abnormality, the embedded system restarts the daemon process according to the updated restart strategy.

[0040] In a third aspect of the present invention, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the daemon process restart method as described above.

[0041] In a fourth aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the daemon process restart method as described above.

[0042] The embodiments of the present invention have the following advantages:

[0043] In this embodiment of the invention, after the daemon process starts, a pre-created unit file is launched. This unit file contains a monitoring script used to monitor the daemon process's running status. Historical fault data for the most recent period is retrieved from the logs at a preset period. This historical fault data is input into a deep learning model, and the recommended restart interval and recommended retries output by the deep learning model are obtained. Based on these recommended restart intervals and retries, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy. The unit file monitors the daemon process's running status. If the daemon process malfunctions, the embedded system restarts it according to the updated restart strategy. Automatic monitoring and restarting of the daemon process can quickly respond to unexpected process termination or abnormal situations, reducing service interruptions or system crashes caused by daemon process failures, thereby improving system stability. It also reduces the need for manual intervention, lowers system maintenance costs and workload, and improves system automation and management efficiency. Furthermore, it avoids service unavailability or performance degradation due to daemon process failures, enhancing user experience and satisfaction, and strengthening the system's competitiveness and market value. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0045] Figure 1 This is a flowchart illustrating the steps of a daemon process restart method according to an embodiment of the present invention;

[0046] Figure 2 This is a flowchart of the steps for starting a unit file according to an embodiment of the present invention;

[0047] Figure 3 This is a flowchart of the steps for restarting a daemon process according to an updated restart strategy provided in an embodiment of the present invention;

[0048] Figure 4 This is a flowchart of a daemon process restart provided in an embodiment of the present invention;

[0049] Figure 5 This is a structural block diagram of a daemon process restart device provided in an embodiment of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details are presented in the various embodiments of the present invention to facilitate a better understanding of this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined with and referenced by each other without contradiction.

[0051] In OpenBMC, Dbus, as a crucial communication mechanism, plays a vital role in system operation. A failure in the Dbus daemon can lead to system malfunctions or even unavailability; therefore, timely detection and recovery from Dbus daemon failures are of paramount importance.

[0052] In this embodiment of the invention, the core concept lies in automatically monitoring the running status of the daemon process through a monitoring script in the systemd unit file, and automatically restarting the daemon process when an abnormality is detected. This proposes a solution for automatically monitoring and restarting daemon processes, applicable to embedded systems using the dbus communication service. It improves system stability, reliability, and user experience while reducing system maintenance costs, and has significant application and promotion value.

[0053] Reference Figure 1 The diagram illustrates a flowchart of a daemon process restart method according to an embodiment of the present invention, which may specifically include the following steps:

[0054] Step 101: After the daemon process starts, a pre-created unit file is started. The unit file contains a monitoring script for monitoring the running status of the daemon process.

[0055] Among them, the unit file is the systemd unit file, which is a configuration file that defines system services, mount points, sockets, devices, and other system resources. These files tell systemd how to manage these resources, including their startup, shutdown, restart, and monitoring behavior. In this embodiment of the invention, its function is to continuously monitor the running status of the daemon process.

[0056] Specifically, in the systemd unit file, you can specify the script to be executed by the monitoring program, monitor-dbus-script.sh. This involves designing the monitoring script, which includes logic for monitoring the daemon process's status. Below is a brief example code:

[0057] #! / bin / bash

[0058] # Check if the Dbus daemon is running

[0059] if pgrep dbus-daemon> / dev / null

[0060] then

[0061] echo "Dbus daenon is running"

[0062] else

[0063] echo""Dbus dacnon is not running, restarting..."

[0064] systemctl restart dbus

[0065] fi

[0066] In this example, the script will check if the daemon is running, and if not, attempt to restart it via systemd. Ensure that the monitor-dbus-script.sh file is saved, and that the monitor-dbus-script.sh script is set to be executable by any systemd unit file created using the command `chmod +x monitor-dbus-script.sh`.

[0067] The command `chmod+x monitor-dbus-script.sh` is a Unix / Linux command used to change file permissions. `chmod` is short for "change mode" and is used to change the permissions of files or directories. `+x` means to add execute permission, and `monitor-dbus-script.sh` is the filename whose permissions are to be changed.

[0068] Step 102: Using a preset period, retrieve the historical fault data for the most recent time period from the log.

[0069] In this embodiment of the invention, when the monitoring detects an anomaly in the daemon process, the logging interface can be called to record the time of the failure, the specific cause, and the subsequent restart and recovery process. After a restart is completed, if the restart fails, the log will record the entire process of the system restarting the daemon process. These logs provide important references for subsequent fault analysis and optimization. By recording fault information, we can better understand the stability of the system operation, identify potential problems, and improve monitoring strategies, thereby improving the reliability and stability of the system.

[0070] Step 103: Input the historical fault data into the deep learning model and obtain the recommended restart interval and recommended retry count output by the deep learning model. Based on the recommended restart interval and recommended retry count output by the deep learning model, dynamically adjust the preset restart strategy to obtain an updated restart strategy.

[0071] In this embodiment of the invention, the restart strategy is likened to a hyperparameter in a deep neural network. By analyzing historical fault data obtained from logs, a method similar to model parameter tuning can be used to determine the optimal restart interval and number of retries. Just like the learning rate in a deep neural network, setting a reasonable restart interval can avoid overly frequent restarts, preventing the system from falling into unnecessary overhead and instability. At the same time, by setting an appropriate number of retries, we can ensure self-healing capabilities while avoiding additional burden on the system.

[0072] Specifically, the restart strategy can be viewed as a dynamically adjusted process, much like how a deep learning model continuously updates its parameters based on changes in the loss function during training. While the system is running, we can continuously monitor the daemon's status and adjust the restart strategy parameters based on real-time data. If multiple consecutive restart failures are detected, the system can automatically reduce the restart frequency or pause the restart process, awaiting manual intervention. This dynamic adjustment mechanism enables the system to more intelligently handle various complex situations, improving its adaptability and robustness.

[0073] We can also consider using deep learning models to predict potential future system failures, thereby enabling more precise restart strategies. By analyzing and modeling historical data, we can train a deep learning model capable of predicting abnormal daemon exits. Then, based on the model's output, we can adjust the restart strategy, taking proactive measures to prevent potential failures and further improving system stability and reliability.

[0074] Step 104: Monitor the running status of the daemon process using the unit file. If the daemon process is abnormal, the embedded system restarts the daemon process according to the updated restart strategy.

[0075] In this embodiment of the invention, the systemd unit file is started to monitor the daemon process. If the daemon process is abnormal, systemd will automatically attempt to restart it.

[0076] Specifically, you can determine if a daemon process is malfunctioning by checking if it exists, or by sending a simple command or query to check if it is responding normally. Additionally, you can monitor the daemon process's log files to check for errors or warnings related to the malfunction. Common daemon process malfunctions include: the daemon process is hanging, the process does not exist, or the process is not hanging but is unresponsive.

[0077] Starting daemons based on updated restart policies enables the system to respond more intelligently to various complex situations, improving system adaptability and robustness, as well as enhancing system stability and reliability.

[0078] Furthermore, in embodiments of the present invention, such as Figure 2 The diagram illustrates a flowchart of the steps for starting a unit file according to an embodiment of the present invention, which may specifically include the following steps:

[0079] Step 1011: Create the unit file in the preset directory.

[0080] Specifically, taking the OpenBMC system as an example, the systemd unit file is usually stored in the / etc / systemd / system / directory and named monitor-dbus.service. The Unit and Service sections of this file need to be configured. An example is shown below:

[0081] [Unit]

[0082] Description=Monitor Dbus service

[0083] After = dbus.service

[0084] [Service]

[0085] Type = simple

[0086] ExecStart= / usr / local / bin / monitor-dbus-script.sh

[0087] Restart = always

[0088] RestartSec=3

[0089] In the example above, monitor-dbus-script.sh is specified as the script to be executed by the monitoring program, which can be configured according to actual needs. The [Unit] section provides a description of the service and specifies that it should be started after dbus.service. The [Service] section contains service-specific configuration options. Type=simple defines the service startup type. Simple is the most common type, meaning that the service is considered active when the command specified by ExecStart is started, and the service is considered stopped if the command returns (i.e., ends). ExecStart= / usr / local / bin / monitor-dbus-script.sh: specifies the command to be executed when the service starts. In this example, the command is / usr / local / bin / monitor-dbus-script.sh, which is a script file. Restart=always defines how the service should be restarted. Always means that the service should be restarted regardless of how it exits (including normal exit, error exit, or being stopped by the system administrator). RestartSec=3: this option defines the time (in seconds) the service should wait before restarting. In this example, the service will wait 3 seconds after stopping before attempting to restart.

[0090] Step 1012: Control the startup of the unit file by obtaining the user's input start service command or configuring the automatic startup function.

[0091] Specifically, users can manually start the service using the command `sudo systemctl start monitor-dbus.service`, or configure the service to start automatically when the system starts. This is a basic function provided by systemd services. By configuring the corresponding parameter items in the service file, the current unit file will be started automatically after the system starts.

[0092] Automatic restart of daemons can also be achieved by creating a Python daemon script that can start automatically. To enable daemons to restart automatically after a crash or termination, a process control system like supervisord can be used. supervisord is a process control system written in Python that can monitor and manage processes. By creating a daemon in the system that can restart automatically and using supervisord to manage daemons, you can ensure that they can restart automatically when needed.

[0093] Furthermore, in this embodiment of the invention, step 102 further includes the following steps:

[0094] Step 1021: Obtain historical fault data of the daemon process restart process in the log for the most recent period according to the restart cycle of the daemon process.

[0095] Specifically, the preset cycle is the cycle for restarting the daemon process, which is divided into two types. One is that after the daemon process starts the restart process, it attempts to restart the daemon process, and one restart attempt is considered as one cycle. The other is that when the number of retries of the daemon process reaches the maximum threshold, that is, the cycle for restarting the daemon process. A single restart of the daemon process includes multiple retries. Based on different cycles, the historical fault data of the most recent daemon process retry or restart is obtained from the log. The obtained historical fault data can provide important reference for subsequent fault analysis and optimization, and can be used to dynamically adjust the restart strategy, so that the system can more intelligently cope with various complex situations, thereby improving the system's adaptability and robustness.

[0096] Furthermore, in embodiments of the present invention, such as Figure 3 The diagram illustrates a flowchart of the steps for restarting a daemon process according to an updated restart policy, as provided in an embodiment of the present invention. Specifically, the steps may include:

[0097] Step 1041: Attempt to restart according to the restart strategy and obtain the first historical fault data during the restart attempt;

[0098] Specifically, the restart strategy records the restart interval value T_r, the number of retry counts N_r, the maximum number of retries N_{max}, the maximum number of restarts R_{max}, and the retry wait time T_w. T_r is the time interval between restarts of the daemon process. N_r is the number of restart attempts, with an initial value of 0 indicating that no attempts have been made when the restart process begins. N_{max} is the maximum allowed number of retries. When N_r reaches (N_{max}), the retry ends. If the number of restarts has not yet reached the maximum number of restarts R_{max}, the restart process continues. A single restart can include multiple restart attempts. The wait time T_w is the waiting time between each restart attempt, used to ensure the complete exit of the previous daemon process or the recovery of system resources. The recommended initial wait time can be from a few seconds to tens of seconds, depending on the system's response speed and the nature of the daemon process.

[0099] When the daemon detects an abnormal exit, the system initiates a restart process. At this point, N_r = 0, and a restart attempt begins. N_r is less than N_{max} at this stage. The initial value of N_{max} is set based on the system's stability requirements and automatic recovery strategy. For example, it can be set to 3 or 5 retries; here, it's set to 3. The system waits for the initial T_w before attempting to restart again. If the restart attempt fails at this point, the first historical fault data of this failed restart attempt is retrieved from the log. This first historical fault data provides important reference for adjusting the restart strategy in subsequent restart attempts.

[0100] Step 1042: If the restart fails, update the retry count, maximum retry count, and retry waiting time in the restart strategy based on the first historical fault data, and continue to attempt to restart according to the updated restart strategy.

[0101] Specifically, based on the historical failure data from the first restart attempt, a deep learning model is used to dynamically adjust the retry count, maximum retry count, and retry waiting time in the restart strategy. The system then continues to attempt to restart based on the updated retry count, maximum retry count, and retry waiting time. Each restart attempt increments N_r by one.

[0102] Step 1043: Repeat the restart attempt steps according to the restart strategy until the restart is successful, or until the number of restart attempts reaches the maximum number of retries after the update.

[0103] Specifically, repeat the process of attempting to restart according to the updated restart strategy, using the same method as steps 1041-1042, but with a different restart strategy and historical fault data, until the restart attempt is successful; or N_r is greater than or equal to N_{max}.

[0104] Step 1044: If the number of restart attempts reaches the updated maximum number of retries, obtain the second historical fault data during the restart process, and update the restart interval value and the maximum number of restarts in the restart strategy based on the second historical fault data;

[0105] Specifically, if N_r is greater than or equal to N_{max}, a restart is performed. This restart failed and included three restart attempts. After waiting for the initial restart interval T_r, the daemon process is restarted again. The second historical data of this restart process, which included three restart attempts, is obtained from the log. Based on the second historical data, the restart interval value T_r and the maximum number of restarts R_{max} in the restart strategy are adjusted using a deep learning model.

[0106] Step 1045: Restart the daemon process according to the updated restart policy.

[0107] Specifically, if the second restart fails, the daemon process will be restarted again according to the restart strategy updated in step 1044.

[0108] Step 1046: Repeat the steps of attempting to restart according to the restart strategy until the restart is successful, or the number of restarts reaches the maximum number of restarts after the update;

[0109] Continue repeating the restart strategy (steps 1041-1044), but using a different restart strategy than the historical fault data, until a successful restart is achieved, or the number of restart attempts reaches R_{max}. If R_{max} is 3, it means that three restarts were completed, with each restart attempt involving three restart attempts.

[0110] Step 1047: If the number of restarts reaches the maximum number of restarts after the update, stop restarting the daemon process and wait for manual intervention.

[0111] Specifically, if R_{max} is 3, it means that three restarts have been completed, and each restart has failed. That is, all three attempts to start the process during each restart have failed. In this case, there is no need to restart the daemon process, and manual intervention is required.

[0112] By using the above operations and adjusting the parameters of the restart strategy through a dynamic adjustment mechanism, the system can more intelligently cope with various complex situations, thereby improving the system's adaptability and robustness.

[0113] Furthermore, in this embodiment of the invention, step 103 further includes the following steps:

[0114] Step 1031: Input the first historical fault data into the deep learning model to obtain the recommended retry count, recommended maximum retry count, and recommended retry waiting time output by the deep learning model;

[0115] Specifically, deep learning models can continuously optimize parameters during training to adapt to various types of data. This application introduces deep learning models to set reasonable retry waiting times and appropriate maximum number of retries.

[0116] Step 1032: Dynamically adjust the restart strategy based on the recommended retry count, the recommended maximum retry count, and the recommended retry waiting time to obtain the updated restart strategy.

[0117] Step 1033: Input the second historical fault data into the deep learning model to obtain the recommended restart interval value and the recommended maximum number of restarts output by the deep learning model;

[0118] Step 1044: Adjust the restart strategy based on the recommended restart interval value and the recommended maximum number of restarts to obtain the updated restart strategy.

[0119] By implementing the above steps, reasonable retry wait times and restart intervals can prevent excessively frequent restarts, thus avoiding unnecessary overhead and instability. Furthermore, by setting appropriate maximum retries and maximum restarts, we can ensure self-healing capabilities while avoiding additional burden on the system.

[0120] Furthermore, in this embodiment of the invention, step 1044 further includes the following steps:

[0121] Step 1044-1: Input the second historical fault data into the deep learning model and obtain the recommended restart interval growth coefficient output by the deep learning model.

[0122] Specifically, the restart strategy also includes a restart interval growth factor \alpha, which can be output based on the deep learning model. This growth factor (\alpha) dynamically adjusts the restart interval (T_r). This factor can be set according to the system's response speed and the restart strategy. Generally, (\alpha) can be a multiple greater than 1 to increase the restart interval and avoid frequent restart attempts. For example, it can be set to 1.5 or 2.

[0123] Step 1044-2: Based on the recommended restart interval value and / or the recommended restart interval growth coefficient, dynamically adjust the restart interval value and / or the restart interval growth coefficient, and use the product of the restart interval value and the restart interval growth coefficient as the recommended restart interval to adjust the restart strategy.

[0124] Specifically, the restart interval T_r = T_r * alpha. When determining the recommended T_r, you can choose to adjust T_r without adjusting alpha, or adjust alpha without adjusting T_r, or adjust both, based on the deep learning model, to determine the optimal restart interval value.

[0125] By performing the above operations and setting a reasonable restart interval value based on the deep learning model, excessively frequent restarts can be avoided, preventing the system from falling into unnecessary overhead and instability.

[0126] In this embodiment of the invention, the pseudocode for restarting the daemon process is as follows:

[0127] When the daemon process exits abnormally;

[0128]

[0129]

[0130] In this strategy, the restart interval (T_r) can be dynamically adjusted based on the value of (\alpha), so that the waiting time between each restart attempt gradually increases or decreases to adapt to different system environments and load conditions.

[0131] Furthermore, in embodiments of the present invention, such as Figure 4 As shown, taking OpenBMC as an example, a flowchart for restarting a daemon process is provided. The specific process is as follows:

[0132] 1. Start the OpenBMC system;

[0133] 2. Start the monitoring service, specifically the systemd unit file monitor-dbus.service;

[0134] 3. Run the monitoring logic, i.e., the monitoring script in the systemd unit file, monitor-dbus-script.sh;

[0135] 4. Scheduled monitoring of the daemon process, i.e., Dbus Daemon;

[0136] 5. Determine if the daemon process is abnormal. If no abnormality is found, continue monitoring the Dbus Daemon.

[0137] 6. If the daemon process is abnormal, the fault detection program will be called for preliminary diagnosis, that is, the systemd unit file will be called to perform abnormal diagnosis on the daemon process.

[0138] 7. Call the logging interface to record fault information;

[0139] 8. Restart the Dbus daemon. After startup is complete, continue monitoring the Dbus Daemon.

[0140] Through the above operations, a complex yet efficient Dbus daemon monitoring system was successfully implemented. When the Dbus daemon encounters an anomaly, systemd will automatically attempt to restart it, thereby ensuring the continuous and stable operation of the system. This intelligent monitoring and self-healing mechanism not only improves the reliability and stability of the system but also reduces reliance on manual intervention, thus enhancing the system's level of automation.

[0141] In this embodiment of the invention, after the daemon process starts, a pre-created unit file is launched. This unit file contains a monitoring script used to monitor the daemon process's running status. Historical fault data for the most recent period is retrieved from the logs at a preset period. This historical fault data is input into a deep learning model, and the recommended restart interval and recommended retries output by the deep learning model are obtained. Based on these recommended restart intervals and retries, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy. The unit file monitors the daemon process's running status. If the daemon process malfunctions, the embedded system restarts it according to the updated restart strategy. Automatic monitoring and restarting of the daemon process can quickly respond to unexpected process termination or abnormal situations, reducing service interruptions or system crashes caused by daemon process failures, thereby improving system stability. It also reduces the need for manual intervention, lowers system maintenance costs and workload, and improves system automation and management efficiency. Furthermore, it avoids service unavailability or performance degradation due to daemon process failures, enhancing user experience and satisfaction, and strengthening the system's competitiveness and market value.

[0142] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0143] Reference Figure 5 The diagram shows a structural schematic of a daemon restart device according to an embodiment of the present invention, which may specifically include the following modules:

[0144] The startup module 201 is used to start a pre-created unit file after the daemon process starts. The unit file contains a monitoring script for monitoring the running status of the daemon process.

[0145] Data acquisition module 202 is used to acquire historical fault data of the most recent period from the log using a preset period;

[0146] The restart strategy adjustment module 203 is used to input the historical fault data into the deep learning model, obtain the recommended restart interval and recommended retry number output by the deep learning model, and dynamically adjust the preset restart strategy based on the recommended restart interval and recommended retry number output by the deep learning model to obtain an updated restart strategy.

[0147] The restart module 204 is used to monitor the running status of the daemon process using the unit file. If the daemon process is abnormal, the embedded system restarts the daemon process according to the updated restart strategy.

[0148] Optionally, the startup module 201 includes:

[0149] Create a module to create the unit file in a preset directory;

[0150] The unit file startup module is used to control the startup of the unit file by obtaining the startup service command input by the user or configuring the automatic startup function.

[0151] Optionally, the data acquisition module 202 includes:

[0152] The log acquisition module is used to retrieve historical fault data of the daemon process restart process from the logs based on the restart cycle of the daemon process.

[0153] Optionally, the restart strategy adjustment module 203 includes:

[0154] Attempt to restart the strategy update module, which is used to input the first historical fault data into the deep learning model and obtain the recommended retry count, recommended maximum retry count, and recommended retry waiting time output by the deep learning model;

[0155] The restart strategy is dynamically adjusted based on the recommended number of retry counts, the recommended maximum number of retry counts, and the recommended retry waiting time to obtain the updated restart strategy.

[0156] Optionally, the restart strategy adjustment module 203 further includes:

[0157] The restart strategy update module is used to input the second historical fault data into the deep learning model and obtain the recommended restart interval value and the recommended maximum number of restarts output by the deep learning model.

[0158] The restart strategy is adjusted based on the recommended restart interval and the recommended maximum number of restarts to obtain the updated restart strategy.

[0159] Optionally, the restart module 204 includes:

[0160] The attempt to restart module is used to attempt to restart according to the restart strategy and obtain the first historical fault data during the attempt to restart;

[0161] If the restart fails, based on the first historical fault data, update the retry count, maximum retry count, and retry waiting time in the restart policy, and continue to attempt to restart according to the updated restart policy;

[0162] Repeat the restart strategy steps as described above until the restart is successful, or until the number of restart attempts reaches the maximum number of retries after the update.

[0163] The restart module is used to obtain second historical fault data during the restart process if the number of restart attempts reaches the updated maximum number of retries, and update the restart interval value and the maximum number of restarts in the restart strategy based on the second historical fault data;

[0164] Restart the daemon process according to the updated restart policy;

[0165] Repeat the steps described above to attempt a restart according to the restart strategy until a successful restart is achieved, or the number of restarts reaches the maximum number of restarts after the update.

[0166] The stop module is used to stop restarting the daemon process if the number of restarts reaches the maximum number of restarts after the update, and wait for manual intervention.

[0167] In this embodiment of the invention, after the daemon process starts, a pre-created unit file is launched. This unit file contains a monitoring script used to monitor the daemon process's running status. Historical fault data for the most recent period is retrieved from the logs at a preset period. This historical fault data is input into a deep learning model, and the recommended restart interval and recommended retries output by the deep learning model are obtained. Based on these recommended restart intervals and retries, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy. The unit file monitors the daemon process's running status. If the daemon process malfunctions, the embedded system restarts it according to the updated restart strategy. Automatic monitoring and restarting of the daemon process can quickly respond to unexpected process termination or abnormal situations, reducing service interruptions or system crashes caused by daemon process failures, thereby improving system stability. It also reduces the need for manual intervention, lowers system maintenance costs and workload, and improves system automation and management efficiency. Furthermore, it avoids service unavailability or performance degradation due to daemon process failures, enhancing user experience and satisfaction, and strengthening the system's competitiveness and market value.

[0168] An embodiment of the present invention also provides an electronic device, which may include a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-mentioned daemon process restart method.

[0169] This invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-described daemon process restart method.

[0170] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0171] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0172] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0173] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0174] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0175] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0176] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the aforementioned element.

[0177] The foregoing has provided a detailed description of the daemon process restart method, apparatus, electronic device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of this invention. Although the implementation methods described above are for ease of understanding, they are not intended to limit the invention. Any modifications and variations made without departing from the spirit and scope of this invention, especially those involving monitoring and automatically restarting critical processes or services, are within the scope of protection of this invention. Similar methods can be applied to various types of systems to improve system stability and availability. Therefore, this specification should not be construed as a limitation of this invention.

Claims

1. A daemon process restart method, applied to an embedded system, characterized in that, The method includes: After the daemon process starts, a pre-created unit file is started. The unit file contains a monitoring script for monitoring the running status of the daemon process. The unit file is used to continuously monitor the running status of the daemon process. Using a preset period, historical fault data for the most recent time period is obtained from the logs; The historical fault data is input into the deep learning model, and the recommended restart interval and recommended retry number output by the deep learning model are obtained. Based on the recommended restart interval and recommended retry number output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy. The embedded system uses the unit file to monitor the running status of the daemon process. If the daemon process encounters an abnormality, the embedded system restarts the daemon process according to the updated restart strategy. The restart strategy includes the restart interval value, retry count value, maximum retry count, maximum restart count, and retry waiting time. If the daemon process encounters an error, the embedded system restarts the daemon process according to the updated restart strategy, including: Attempt to restart according to the restart policy and obtain the first historical fault data during the restart attempt; If the restart fails, the retry count, maximum retry count, and retry waiting time in the restart strategy are updated based on the first historical fault data, and the restart attempt is continued according to the updated restart strategy; each restart includes at least one restart attempt. Repeat the restart strategy steps as described above until the restart is successful, or until the number of restart attempts reaches the maximum number of retries after the update. If the number of restart attempts reaches the updated maximum number of retries, obtain the second historical fault data during the restart process, and update the restart interval value and the maximum number of restarts in the restart strategy based on the second historical fault data; Restart the daemon process according to the updated restart policy; Repeat the steps described above to attempt a restart according to the restart strategy until a successful restart is achieved, or the number of restarts reaches the maximum number of restarts after the update. If the number of restarts reaches the maximum number of restarts after the update, stop restarting the daemon process and wait for manual intervention.

2. The method according to claim 1, characterized in that, The pre-created unit file for startup includes: Create the unit file in the preset directory; The unit file can be started by obtaining the user's input command to start the service, or by configuring an automatic startup function.

3. The method according to claim 1, characterized in that, The preset period is the period during which the daemon process restarts; Using a preset period, retrieve historical fault data from the logs for the most recent time period, including: Based on the restart cycle of the daemon process, retrieve historical fault data of the daemon process restart process in the most recent period from the log.

4. The method according to claim 1, characterized in that, The historical fault data is input into a deep learning model, and the recommended restart interval and recommended retry count output by the deep learning model are obtained. Based on the recommended restart interval and recommended retry count output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy, including: Input the first historical fault data into the deep learning model to obtain the recommended retry count, recommended maximum retry count, and recommended retry waiting time output by the deep learning model. The restart strategy is dynamically adjusted based on the recommended number of retry counts, the recommended maximum number of retry counts, and the recommended retry waiting time to obtain the updated restart strategy.

5. The method according to claim 1, characterized in that, The historical fault data is input into a deep learning model, and the recommended restart interval and recommended retry count output by the deep learning model are obtained. Based on the recommended restart interval and recommended retry count output by the deep learning model, the preset restart strategy is dynamically adjusted to obtain an updated restart strategy, which also includes: Input the second historical fault data into the deep learning model to obtain the recommended restart interval value and the recommended maximum number of restarts output by the deep learning model; The restart strategy is adjusted based on the recommended restart interval and the recommended maximum number of restarts to obtain the updated restart strategy.

6. The method according to claim 5, wherein the restart strategy further includes a restart interval growth coefficient; The restart strategy is adjusted based on the recommended restart interval and the recommended maximum number of restarts to obtain an updated restart strategy, including: Input the second historical fault data into the deep learning model to obtain the recommended restart interval growth coefficient output by the deep learning model; Based on the recommended restart interval value and / or the recommended restart interval growth coefficient, the restart interval value and / or the restart interval growth coefficient are dynamically adjusted, and the product of the restart interval value and the restart interval growth coefficient is used as the recommended restart interval to adjust the restart strategy.

7. A daemon restart device, characterized in that, The device includes: The startup module is used to start a pre-created unit file after the daemon process starts. The unit file contains a monitoring script for monitoring the running status of the daemon process. The unit file is used to continuously monitor the running status of the daemon process. The data acquisition module is used to retrieve historical fault data for the most recent period from the logs using a preset period. The restart strategy adjustment module is used to input the historical fault data into the deep learning model, obtain the recommended restart interval and recommended retry number output by the deep learning model, and dynamically adjust the preset restart strategy based on the recommended restart interval and recommended retry number output by the deep learning model to obtain an updated restart strategy. The restart module is used to monitor the running status of the daemon process using the unit file. If the daemon process is abnormal, the embedded system restarts the daemon process according to the updated restart strategy. The restart strategy includes the restart interval value, retry count value, maximum retry count, maximum restart count, and retry waiting time. The restart module includes: The attempt to restart module is used to attempt to restart according to the restart strategy and obtain the first historical fault data during the attempt to restart; If the restart fails, the retry count, maximum retry count, and retry waiting time in the restart strategy are updated based on the first historical fault data, and the restart attempt is continued according to the updated restart strategy; each restart includes at least one restart attempt. Repeat the restart strategy steps as described above until the restart is successful, or until the number of restart attempts reaches the maximum number of retries after the update. The restart module is used to obtain second historical fault data during the restart process if the number of restart attempts reaches the updated maximum number of retries, and update the restart interval value and the maximum number of restarts in the restart strategy based on the second historical fault data; Restart the daemon process according to the updated restart policy; Repeat the steps described above to attempt a restart according to the restart strategy until a successful restart is achieved, or the number of restarts reaches the maximum number of restarts after the update. The stop module is used to stop restarting the daemon process if the number of restarts reaches the maximum number of restarts after the update, and wait for manual intervention.

8. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method for restarting a daemon process as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method for restarting a daemon process as described in any one of claims 1 to 6.

Images