Gatekeeper management method and apparatus, electronic device, and computer-readable storage medium

Abstract

The embodiment of the application discloses a watchdog management method and device, electronic equipment and a computer readable storage medium, and belongs to the technical field of computers. The method comprises the following steps: in response to the watchdog calling a monitoring interface of a storage management service in a current thread, obtaining a bottom-layer storage daemon process object; when the bottom-layer storage daemon process object is not empty, submitting a monitoring task of the bottom-layer storage daemon process to a background executor, so that the background executor executes the monitoring task in a background thread, and ends the calling of the monitoring interface. The embodiment of the application ensures that the watchdog mechanism can normally complete the detection on the activity of the system core service, fundamentally eliminates the risk that the system is mistakenly restarted due to external device failure, and greatly improves the stability and robustness of the system when facing abnormal external storage.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a watchdog management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] In operating systems, the watchdog mechanism is responsible for monitoring the activity of the core system service `system_server`. As one of these system services, the StorageManagerService's monitoring interface is periodically invoked by the watchdog.

[0003] In related technologies, the monitoring interface synchronously calls the underlying storage daemon interface. When external storage devices (such as SD cards (Secure Digital Memory Cards)) experience abnormalities or slow I / O (input / output), this synchronous call path may be blocked for a long time, causing the Watchdog to time out and triggering a system_server restart, which seriously affects system stability and user experience. Summary of the Invention

[0004] This application provides a watchdog management method, apparatus, electronic device, and computer-readable storage medium, which can prevent the storage management service monitoring interface from being blocked for a long time due to abnormal external storage devices, thereby preventing the watchdog mechanism from misjudging and triggering a system restart.

[0005] In a first aspect, embodiments of this application provide a watchdog management method, including: In response to the watchdog calling the monitoring interface of the storage management service in the current thread, the underlying storage daemon object is obtained; When the underlying storage daemon object is not empty, the monitoring task of the underlying storage daemon is submitted to the background executor so that the background executor executes the monitoring task in a background thread and terminates the call to the monitoring interface.

[0006] In one embodiment, submitting the monitoring task of the underlying storage daemon to the background executor includes: Read atomic state variables; the atomic state variables include a first state and a second state, the first state is used to indicate that there is currently no running monitoring task, and the second state is used to indicate that there is currently a running monitoring task; When the atomic state variable is in the first state, the monitoring task of the underlying storage daemon is submitted to the background executor, and the atomic state variable is switched from the first state to the second state; The method further includes: When the atomic state variable is in the second state, the submission of the monitoring task for the background executor is skipped, and the monitoring interface returns in the current thread.

[0007] In one embodiment, the method further includes: In response to the completion of the monitoring task in the background thread, the atomic state variable is switched from the second state to the first state.

[0008] In one embodiment, the method further includes: In response to detecting an abnormal event generated during the execution of the monitoring task by the background executor, the abnormal event is recorded and the transmission of the abnormal event to the current thread is prohibited.

[0009] In one embodiment, the method further includes: The execution time of the monitoring task is recorded in the background thread; When the execution duration of the task exceeds a first duration threshold, a slow monitoring event is recorded; Based on the recorded information of the slow monitoring events, the submission frequency of subsequent monitoring tasks is adjusted.

[0010] In one embodiment, the recorded information includes the cumulative number of times the slow monitoring event occurs consecutively; The adjustment of the submission frequency of subsequent monitoring tasks based on the recorded information of the slow monitoring events includes: When the cumulative number of attempts reaches a threshold, a frequency reduction detection strategy is executed until a preset recovery condition is met; wherein, the frequency reduction detection strategy includes: Within at least two watchdog cycles, the monitoring task is submitted only in one of the watchdog cycles; and / or, Obtain the end time of the last monitoring task completion or timeout, and skip submitting the monitoring task to the background executor if the time interval between the current time and the end time is less than a second duration threshold.

[0011] In one embodiment, the preset recovery condition includes any of the following conditions: External storage device detected has been removed; External storage volume remount detected; The task execution time is less than or equal to the first time threshold.

[0012] Secondly, embodiments of this application provide a watchdog management device, the device comprising: The object retrieval module is used to retrieve the underlying storage daemon object in response to the watchdog calling the monitoring interface of the storage management service in the current thread. The task submission module is used to submit the monitoring task of the underlying storage daemon process to the background executor when the underlying storage daemon process object is not empty, so that the background executor executes the monitoring task in a background thread and terminates the call to the monitoring interface.

[0013] In one embodiment, the task submission module includes: The variable reading submodule is used to read atomic state variables; the atomic state variables include a first state and a second state, the first state is used to indicate that there is currently no running monitoring task, and the second state is used to indicate that there is currently a running monitoring task; The task submission submodule is used to submit the monitoring task of the underlying storage daemon to the background executor when the atomic state variable is in the first state, and to switch the atomic state variable from the first state to the second state. The watchdog management device also includes: The task skip module is used to skip the submission of the monitoring task to the background executor when the atomic state variable is in the second state, and the monitoring interface returns in the current thread.

[0014] In one embodiment, the watchdog management device further includes: A state switching module is used to switch the atomic state variable from the second state to the first state in response to the completion of the monitoring task in the background thread.

[0015] In one embodiment, the watchdog management device further includes: The exception logging module is used to respond to an exception event that occurs during the execution of the monitoring task by the background executor, record the exception event, and prevent the exception event from being passed to the current thread.

[0016] In one embodiment, the watchdog management device further includes: The time recording module is used to record the execution duration of the monitoring task in the background thread; The event logging module is used to record slow monitoring events when the task execution time exceeds a first duration threshold. The frequency adjustment module is used to adjust the submission frequency of subsequent monitoring tasks based on the recorded information of the slow monitoring events.

[0017] In one embodiment, the recorded information includes the cumulative number of consecutive occurrences of the slow monitoring event; the frequency adjustment module includes: A frequency reduction detection submodule is used to execute a frequency reduction detection strategy when the cumulative number of attempts reaches a threshold, until a preset recovery condition is met; wherein, the frequency reduction detection strategy includes: Within at least two watchdog cycles, the monitoring task is submitted only in one of the watchdog cycles; and / or, Obtain the end time of the last monitoring task completion or timeout, and skip submitting the monitoring task to the background executor if the time interval between the current time and the end time is less than a second duration threshold.

[0018] In one embodiment, the preset recovery condition includes any of the following conditions: External storage device detected has been removed; External storage volume remount detected; The task execution time is less than or equal to the first time threshold.

[0019] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the watchdog management method described above.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the watchdog management method described above.

[0021] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in the embodiments of this application.

[0022] In summary, in this embodiment, in response to the watchdog calling the monitoring interface of the storage management service in the current thread, the underlying storage daemon object can be obtained. If the underlying storage daemon object is not empty, the monitoring task of the underlying storage daemon process is submitted to the background executor, allowing the background executor to execute the monitoring task in a background thread and terminate the call to the monitoring interface. This embodiment effectively avoids prolonged blocking of the monitoring interface caused by external storage device anomalies by switching the originally synchronous execution of the underlying storage monitoring task to asynchronous execution in a background thread and ensuring the monitoring interface returns immediately after being called. This ensures that the watchdog mechanism can normally complete the detection of the activity of the system's core services, fundamentally eliminating the risk of the system being mistakenly restarted due to peripheral device failure, and greatly improving the system's stability and robustness in the face of abnormal external storage. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the 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.

[0024] Figure 1 This is a flowchart illustrating a watchdog management method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a specific embodiment of the submission monitoring task provided in this application; Figure 3 This is a schematic diagram of a specific embodiment of the watchdog management method provided in this application; Figure 4 This is a schematic diagram of the structure of a watchdog management device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0026] It's important to note that the Android operating system incorporates a Watchdog mechanism to ensure the stability of the core process `system_server`. This mechanism polls and checks a series of critical system services within `system_server` at fixed intervals. To do this, these services need to implement a monitoring interface (`monitor()`). The Watchdog calls the `monitor()` method of each service sequentially in its dedicated thread, expecting them to return within a preset timeframe. If any service's `monitor()` call exceeds the timeout (e.g., 30 or 60 seconds), the Watchdog determines that `system_server` is in a deadlock or unrecoverable blocked state, forcibly kills the process, and triggers a system restart.

[0027] StorageManagerService (SMS) is one of the core services in system_server, responsible for managing all storage volumes within the system, including internal and external storage devices such as SD cards (Secure Digital Memory Cards) and USB OTG (Universal Serial Bus On-The-Go) devices. In its current implementation, the monitor() method synchronously calls the monitor() interface of the underlying storage daemon (vold) via inter-process communication (IPC). The intention behind this design is to check the health of the underlying storage daemon while simultaneously checking the status of SMS itself.

[0028] However, the inventors of this application have discovered serious flaws in this design during practical application. The quality of external storage devices (especially user-purchased SD cards) varies greatly, and during use, unpredictable long-term blocking of I / O operations can easily occur due to physical aging, file system logic errors, poor contact, or slow read / write speeds. Since StorageManagerService.monitor() synchronously waits for the return result of vold.monitor(), any underlying call blocking caused by external storage exceptions will directly prevent the monitor() method from returning on time. Furthermore, Watchdog cannot distinguish whether this blocking stems from a deadlock within the system_server itself or from a slow external device; the only fact it can confirm is that the SMS service failed to respond within the specified time.

[0029] Therefore, the relevant technologies incorrectly couple the health status of the core system services with the real-time responsiveness of external physical devices. Peripheral-level failures, which should be confined within the storage subsystem, are amplified into a fatal system-level error through this synchronous call path, ultimately causing the system_server process to be forcibly restarted by the Watchdog. This erroneous restart not only risks interrupting current user operations and data loss, but also severely damages the brand reputation and user experience of devices with extremely high stability requirements, such as smart TVs and in-vehicle systems. Although related technologies attempt to mitigate this problem by adjusting the Watchdog timeout threshold or optimizing the storage driver, these methods either sacrifice the ability to detect true deadlocks or fail to cover all abnormal scenarios, thus failing to fundamentally solve the aforementioned technical problems.

[0030] To address the issue of watchdog timer malfunctions triggering erroneous system restarts due to external storage device failures, this application aims to provide a watchdog management method. By switching the previously synchronous underlying storage monitoring task to asynchronous execution in a background thread, and ensuring the monitoring interface returns immediately upon being invoked, this effectively avoids prolonged blocking of the monitoring interface caused by external storage device failures. This method ensures the watchdog mechanism can correctly detect the activity of core system services, fundamentally eliminating the risk of erroneous system restarts due to peripheral device failures, and significantly improving the system's stability and robustness in the face of abnormal external storage.

[0031] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0032] Figure 1 The illustration shows a schematic flowchart of a watchdog management method according to an embodiment of this application. The execution entity of the watchdog management method can be a watchdog management device, which can be integrated into any electronic device with data processing, network communication, and program execution functions. The electronic device can be a server or a terminal, etc.

[0033] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), as well as big data and artificial intelligence platforms.

[0034] The terminal can be a mobile phone, tablet computer, laptop computer, desktop computer, smart home device, wearable smart device, in-vehicle computer, or industrial control equipment, but is not limited to these. The terminal and server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0035] In this embodiment, the description will be from the perspective of a watchdog management device, which can be integrated into a server or terminal. To facilitate the explanation of the watchdog management method of this application, the watchdog management device will be used as the execution subject for detailed explanation below.

[0036] The terms used in the embodiments of this application are explained below.

[0037] Watchdog: refers to the watchdog mechanism built into the system_server process in the Android system, used to periodically check whether the core services of the system are active.

[0038] Storage Manager Service (SMS): One of the core system services in system_server, responsible for managing the mounting, unmounting, and status monitoring of internal and external storage devices (such as SD cards, USB OTG devices, etc.).

[0039] The monitoring interface is the monitor method that the watchdog requires each system service to implement. The watchdog will call the monitor method of each service in its dedicated thread at fixed time intervals. If the monitor call of a certain service does not return after the preset time limit, the watchdog will determine that the process of that service has deadlocked and trigger the process to restart.

[0040] The underlying storage daemon (vold) is a low-level storage volume management daemon that runs as an independent process in the Android system and is responsible for interacting directly with the storage hardware.

[0041] Executor: In the Java concurrency framework, the task executor is used to submit tasks to background threads for execution, thereby achieving thread isolation between the calling thread and the called task.

[0042] Reference Figure 1 The diagram shows a flowchart of a watchdog management method according to this application. The method may specifically include steps S101 to S102, as follows: S101: In response to the watchdog calling the monitoring interface of the storage management service in the current thread, obtain the underlying storage daemon object.

[0043] In this implementation, when the watchdog mechanism reaches its periodic check process, the watchdog thread sequentially calls the monitor methods of each registered system service. When the monitor method of the StorageManagerService is called, this method is triggered and executed, and the current execution thread is the system thread to which the watchdog belongs. At the entry point of this monitor method, the operation of obtaining the underlying storage daemon process object is performed first.

[0044] In this embodiment, considering that in the Android system architecture, StorageManagerService internally maintains a reference to the Binder proxy object of the vold service, which is the underlying storage daemon object, this embodiment can obtain the underlying storage daemon object by reading the vold service reference variable already established in StorageManagerService. It should be noted that if the system has not yet completed the initialization of the storage service, or if the vold service fails to start normally due to an abnormal reason, the value of this reference variable may be null.

[0045] In this embodiment, by first obtaining the underlying storage daemon object, a foundation can be provided for subsequently determining whether the prerequisites for executing monitoring tasks are met.

[0046] S102: When the underlying storage daemon object is not empty, submit the monitoring task of the underlying storage daemon to the background executor so that the background executor can execute the monitoring task in the background thread and end the call to the monitoring interface.

[0047] In this implementation, if the underlying storage daemon object is null, it indicates that the vold service is unavailable in the current system environment. In this case, any attempt to call the vold service interface will fail. The monitoring interface should return immediately to avoid exceptions caused by calling an invalid object reference.

[0048] In this implementation, when it is confirmed that the underlying storage daemon object is not null, it indicates that the vold service is currently available and has the conditions to perform a storage health check. At this time, instead of directly calling the vold service's monitor interface synchronously in the current watchdog thread, the call to this interface is encapsulated as a monitoring task (Runnable or Callable object), and this task is submitted to a separate background executor.

[0049] In this embodiment, the background executor is pre-configured with independent thread resources, the specific implementation of which is not limited. It can be a single-threaded thread pool (SingleThreadExecutor), a bounded queue thread pool, a serial executor (SerialExecutor), or a message dispatch mechanism based on HandlerThread. Preferably, a single-threaded serial executor can be used to avoid putting additional pressure on the underlying storage daemon process by executing multiple monitoring tasks in parallel.

[0050] In this implementation, the monitoring task involves calling the `monitor` method of the underlying storage daemon object, i.e., executing `vold.monitor`. After the monitoring task is submitted to the background executor, the background executor allocates an idle background thread from its managed thread pool to execute the task. At this point, the monitoring task executes asynchronously in the new background thread, completely decoupled from the watchdog thread. Therefore, even if the monitoring task is blocked for a long time due to an external storage device malfunction, the blockage is limited to the background thread and will not propagate to the watchdog thread. Meanwhile, in the current watchdog thread, the monitoring interface returns immediately after submitting the monitoring task, without waiting for the task to complete. Since the return of the monitoring interface no longer depends on the completion of the underlying storage call, its return time depends only on the time taken by the task submission operation itself, which is typically only in the microsecond to millisecond range, far less than the watchdog's timeout threshold. Thus, the watchdog mechanism can normally detect and determine the activity status of the storage management service and will not trigger a system restart due to an external storage device malfunction.

[0051] In this implementation, when the underlying storage daemon object is empty, or when the monitoring task has been successfully submitted to the background executor and the call has ended, the monitoring interface performs a return operation, handing the execution flow back to the watchdog thread. This return operation signifies that the storage management service has completed its response to the watchdog check during this monitoring cycle.

[0052] The technical solution adopted in this application switches the originally synchronous execution of underlying storage monitoring calls to asynchronous background execution, enabling the monitoring interface of the storage management service to return immediately after being called by the watchdog. In this way, the watchdog mechanism can accurately distinguish between the deadlock state of the system service itself and the slow I / O state caused by peripheral devices, fundamentally eliminating the risk of watchdog misjudgment and triggering erroneous restarts of system service processes due to external storage device anomalies. Therefore, while fully retaining the ability to continuously monitor the underlying storage state, it significantly improves the stability and robustness of the system when facing abnormal external storage devices, thus improving the user experience.

[0053] In one feasible implementation, refer to Figure 2The step of submitting the monitoring task of the underlying storage daemon to the background executor in S102 can specifically include steps S201~S202, as follows: S201: Read atomic state variables.

[0054] In this embodiment, the watchdog management device maintains an atomic state variable, which indicates whether an underlying storage monitoring task is currently running in the background executor. The atomic state variable referred to in this application embodiment is a variable declared based on the AtomicBoolean type in the Java concurrency package (java.util.concurrent.atomic). The core characteristic of atomic state variables is that read, compare, and update operations on them are atomic; that is, these operations will not be interrupted or interfered with by operations of other threads in a multi-threaded concurrent environment.

[0055] In this embodiment, the atomic state variable includes a first state and a second state. The first state indicates that there is currently no running monitoring task, that is, the background executor is not currently executing the vold.monitor call and is in an idle or ready-to-submit-new-task state; the second state indicates that there is currently a running monitoring task, that is, a monitoring task is already being executed in the background executor, and no new monitoring task should be submitted at this time.

[0056] In one specific implementation, an AtomicBoolean variable mVoldMonitorRunning can be used to represent this atomic state variable. When its value is false, it corresponds to the first state (no task running), and when its value is true, it corresponds to the second state (task running). This embodiment does not specifically limit the type and form of the atomic state variable.

[0057] It's important to note that in the watchdog mechanism, the watchdog thread calls the `monitor` method of each system service at fixed intervals (e.g., every 30 or 60 seconds). Since I / O operations on external storage devices can take several seconds or even tens of seconds, the next monitoring cycle may arrive before the previous monitoring task has finished. If new tasks are submitted to the background executor without control, multiple monitoring tasks will queue and accumulate in the background executor, consuming thread and memory resources, and potentially exhausting the thread pool and causing more serious system problems. Therefore, before submitting each monitoring task, the current value of the atomic state variable must be read to determine if a monitoring task is already running.

[0058] S202: When the atomic state variable is in the first state, submit the monitoring task of the underlying storage daemon to the background executor and switch the atomic state variable from the first state to the second state.

[0059] In this implementation, after reading the atomic state variable, if the atomic state variable currently indicates the first state, it means that there is currently no running monitoring task, and this call meets the conditions for submitting a new task. At this time, the monitoring task of the underlying storage daemon is submitted to the background executor. The content of this monitoring task is to call the monitor method of the underlying storage daemon object. At the same time, the atomic state variable is atomically switched from the first state to the second state to mark that a monitoring task is currently running.

[0060] In this embodiment, the watchdog management method may further include: when the atomic state variable is in the second state, skipping the submission of the monitoring task for the background executor, and the monitoring interface returning in the current thread.

[0061] In this implementation, when the atomic state variable is in the second state, it indicates that a monitoring task is already running in the background executor. In this case, the current monitoring interface call will not submit a new monitoring task to the background executor, but will skip the task submission operation and return immediately in the current watchdog thread. Through this mechanism, even in the extreme case of continuous abnormalities in the external storage device, where the watchdog periodically and repeatedly calls the monitoring interface, there will always be at most one monitoring task running in the background executor. Excessive monitoring calls will not lead to task backlog; they will only return quickly at a very low cost, avoiding the risk of resource exhaustion.

[0062] The technical solution adopted in this application introduces a concurrency control mechanism based on atomic state variables during the monitoring task submission process, ensuring that at most one monitoring task is running in the background executor at any given time. This effectively prevents duplicate submissions of monitoring tasks and accumulation of background thread resources caused by periodic watchdog calls. Thus, it can ensure thread safety while maintaining execution efficiency, enabling the monitoring interface to remain lightweight and responsive even under high-concurrency call scenarios, further enhancing the system's long-term stable operation under abnormal external storage conditions.

[0063] In one feasible implementation, the watchdog management method may further include: switching an atomic state variable from a second state to a first state in response to the completion of a monitoring task in a background thread.

[0064] In this implementation, after the monitoring task is submitted to the background executor, the background thread begins executing the monitoring task. During execution, the monitoring task calls the monitor method of the underlying storage daemon to perform a health check on the external storage device. When this call is completed, regardless of whether the underlying storage daemon returns normally, throws an exception, or the call terminates for other reasons, the monitoring task is considered to have completed.

[0065] In a preferred implementation, the step of switching the atomic state variable from the second state to the first state may specifically include: switching the atomic state variable from the second state to the first state via a finally block. Specifically, by implementing state recovery in the finally block of the monitoring task code, it can be ensured that the state recovery operation can be reliably executed regardless of the reason for the monitoring task's termination (including normal completion, throwing an exception, or termination due to an underlying error). That is, after the monitoring task completes, an update operation on the atomic state variable is performed, switching the atomic state variable from the second state back to the first state to indicate that there is currently no running monitoring task.

[0066] In this implementation, when a monitoring task is blocked for an extended period due to an external storage device malfunction, if the blockage is eventually resolved (e.g., device response resumes, I / O operation completes, or timeout returns), the atomic state variable must be reset to the first state. Otherwise, subsequent monitoring interface calls in the watchdog cycle will continuously skip task submission due to reading the second state, causing the storage monitoring function to fail for an extended period. By unconditionally performing state restoration in the finally block at the end of the task, the monitoring logic can be ensured to have self-healing capabilities, preventing the monitoring function from permanently stopping due to a single exception.

[0067] By adopting the technical solution of this application embodiment, the atomic state variables are automatically restored after the monitoring task is completed, so that the monitoring function can resume normal scheduling after a single task ends, thereby ensuring the long-term sustainable operation of the monitoring mechanism, effectively avoiding the problem of state residue caused by abnormal exit, and further enhancing the self-healing capability and reliability of the system.

[0068] In one feasible implementation, the watchdog management method may further include: in response to detecting an abnormal event generated during the execution of a monitoring task by a background executor, logging the abnormal event and preventing the abnormal event from being passed to the current thread.

[0069] In this implementation, after the monitoring task is submitted to the background executor, the background thread executes the `monitor` method call to the underlying storage daemon process. During this process, due to potential issues such as physical aging of the external storage device, file system corruption, poor contact, or read / write timeouts, the call may throw various exception events. These exception events refer to various detectable abnormal conditions that the monitoring task may throw during execution, including but not limited to: `RemoteException` (inter-process communication exception, typically indicating the termination of the vold service process or a broken Binder communication link), `RuntimeException` (runtime exception, possibly indicating an illegal state in the underlying call), storage daemon process communication failure, and `IOException` (input / output exception, possibly indicating storage medium read / write errors).

[0070] In this implementation, when a background thread detects the aforementioned abnormal event during the execution of a monitoring task, it does not directly ignore the exception or allow it to propagate. Instead, it first records the abnormal event. This recording operation includes, but is not limited to, outputting an exception log through a system log interface (such as Log.e), recording the exception type, exception message, and exception stack information to facilitate subsequent problem diagnosis and fault location. Secondly, it prohibits the transmission of the abnormal event to the current thread. The current thread refers to the watchdog thread that calls the storage management service monitoring interface.

[0071] In practical implementation, a try-catch block can be used to wrap the call to `vold.monitor` in the execution code of the monitoring task. After recording the exception in the catch block, the exception is not re-thrown, allowing it to be swallowed within the background thread. Thus, even if the underlying storage call throws an exception, it will not be propagated across threads to the watchdog thread, nor will it cause the watchdog thread to terminate abnormally due to receiving an uncaught exception.

[0072] By employing the technical solution of this application embodiment, and by performing non-fatal processing on abnormal events during the execution of monitoring tasks, the abnormality of external storage devices is effectively isolated from the execution path of the system core service threads. This ensures that even if the underlying storage calls frequently throw exceptions, the watchdog thread can still complete the detection of the system service activity normally, further enhancing the system's fault tolerance and stability when facing abnormal peripherals.

[0073] In one feasible implementation, the watchdog management method may further include: in response to detecting an abnormal event generated during the execution of a monitoring task by a background executor, logging the abnormal event and preventing the abnormal event from being passed to the current thread.

[0074] In this implementation, after the monitoring task is submitted to the background executor, the background thread begins executing the monitoring task. During execution, the execution duration of the monitoring task is observed and recorded. Specifically, the start time is recorded when the monitoring task begins execution, and the end time is recorded when the monitoring task is completed (including normal completion or termination due to an exception). The difference between the end time and the start time is taken as the execution duration of this monitoring task, which reflects the total time elapsed from initiating the monitor call to the underlying storage daemon process to the return of the call.

[0075] In this embodiment, after obtaining the task execution time, it is compared with a preset first duration threshold. The first duration threshold is a pre-configured time threshold used to distinguish between normal monitoring time and abnormal slow monitoring time. This threshold can be set according to the system's tolerance for storage monitoring response time, for example, it can be set to 10 seconds, 20 seconds, or 30 seconds. When the task execution time exceeds the first duration threshold, it indicates that the response speed of the underlying storage device is significantly lower than normal, and this monitoring event is recorded as a slow monitoring event. The recorded content of the slow monitoring event may include, but is not limited to: the task execution time of this monitoring, the timestamp of occurrence, and the corresponding storage device identifier, to facilitate subsequent analysis and tracking of abnormal patterns.

[0076] In this implementation, after recording slow monitoring events, the submission frequency of subsequent monitoring tasks will be adjusted based on the recorded information. The recorded information may include multiple dimensions such as the number of slow monitoring events occurring, the number of consecutive occurrences, and the distribution of occurrence times.

[0077] In practical implementation, when the logged information indicates that slow monitoring events are only occasional, the current submission frequency can be maintained. However, when the logged information indicates that slow monitoring events are occurring continuously or frequently, the submission frequency of subsequent monitoring tasks should be reduced. The specific methods for adjusting the submission frequency can be varied, such as increasing the submission interval of monitoring tasks or selecting only a portion of the multiple watchdog cycles to submit monitoring tasks. Through this dynamic adjustment mechanism, the system can adaptively adjust the monitoring intensity based on the real-time response status of external storage devices, proactively reducing the frequency of access to abnormal devices when they malfunction, thereby avoiding continuous pressure on background thread resources and overall system performance caused by frequent submissions of slow monitoring tasks.

[0078] By adopting the technical solution of this application embodiment, by introducing the recording of task execution time, the determination of slow monitoring events, and the dynamic adjustment mechanism of submission frequency based on the recorded information in the background thread, the quantitative perception and adaptive response to the severity of storage device anomalies are realized. This avoids the background thread resources being occupied ineffectively for a long time when the device is continuously abnormal, and further improves the resource utilization efficiency and long-term operational stability of the system under abnormal storage conditions.

[0079] In one feasible implementation, the recorded information includes the cumulative number of consecutive slow monitoring events. The step of adjusting the submission frequency of subsequent monitoring tasks based on the recorded information of slow monitoring events may specifically include: when the cumulative number reaches a threshold, executing a frequency reduction detection strategy until a preset recovery condition is met; wherein the frequency reduction detection strategy includes: submitting a monitoring task only in one of at least two watchdog cycles; and / or, obtaining the end time of the last monitoring task completion or timeout, and skipping the submission of monitoring tasks to the background executor when the time interval between the current time and the end time is less than a second duration threshold.

[0080] In this implementation, after executing the monitoring task in a background thread and recording the task execution duration, when the task execution duration exceeds a first duration threshold, the system records a slow monitoring event and maintains a cumulative count to record consecutive slow monitoring events. This cumulative count refers to the number of consecutive slow monitoring events since the most recent normal execution of the monitoring task (i.e., the task execution duration did not exceed the first duration threshold). Each time a slow monitoring event occurs, the cumulative count is incremented by one; when a normal monitoring event occurs (the task execution duration does not exceed the first duration threshold), the cumulative count is reset to zero.

[0081] In this embodiment, the watchdog management device has a preset threshold for the number of occurrences. This threshold is used to determine whether the anomaly of the external storage device has reached a level requiring active intervention. This threshold can be configured according to the actual application scenario and the system's tolerance for storage anomalies; for example, it can be set to 3, 5, or 10 occurrences. When the cumulative number of occurrences reaches this threshold, it indicates that the storage device has repeatedly experienced slow responses, and this slow response state is continuous and stable, not just occasional fluctuations. At this time, a frequency reduction detection strategy will be implemented to reduce the intensity of access to the abnormal storage device.

[0082] In this embodiment, the frequency reduction detection strategy refers to a control rule that actively reduces the frequency of monitoring task submissions. This strategy aims to reduce invalid, repeated probing of abnormal storage devices, conserve background thread resources, and avoid increasing the device's I / O burden due to high-frequency monitoring task submissions. Specifically, the frequency reduction detection strategy includes the following two optional methods: The first frequency reduction detection method involves submitting a monitoring task only in one of at least two watchdog cycles. In a specific implementation, the system maintains a cycle counter. This counter increments each time the watchdog calls the monitoring interface. Only when the counter reaches a preset number of frequency reduction cycles (e.g., every three watchdog cycles) is a monitoring task allowed to be submitted; submissions are skipped in all other cycles. For example, setting the frequency reduction parameter to 3 means that a monitoring task is submitted only in one out of every three watchdog cycles, reducing the monitoring frequency to one-third of the original. The frequency reduction parameter can be dynamically adjusted based on the severity of the anomaly; the more severe the anomaly, the larger the value of the frequency reduction parameter.

[0083] The second frequency reduction detection method involves obtaining the end time of the last monitoring task's completion or timeout, and skipping the submission of the monitoring task to the background executor when the time interval between the current time and the end time is less than a second duration threshold. Here, the timeout end time refers to the moment when the detected task execution duration exceeds a first duration threshold. Specifically, the watchdog management device can record the end time of the last monitoring task (regardless of whether the task was completed normally or terminated due to timeout). When the watchdog calls the monitoring interface again, it calculates the time difference between the current time and the end time. If this time difference is less than a preset second duration threshold (e.g., 30 seconds or 60 seconds), it indicates that the time since the last monitoring completion is still short, and the storage device may still be in an abnormal state. In this case, the current task submission is skipped, and the monitoring interface returns directly in the current thread. Thus, by using the absolute time interval as the basis for frequency reduction, rather than the watchdog cycle count, it can provide more stable frequency reduction interval control, unaffected by changes in the watchdog cycle.

[0084] It should be noted that the two frequency reduction detection strategies described above can be combined using an AND / OR relationship. That is, only the first method, only the second method, or both methods can be used simultaneously. When both methods are used simultaneously, if the skip condition of either method is met, the monitoring task will not be submitted this time. The execution of the frequency reduction detection strategy will continue until the preset recovery condition is met, at which point the frequency reduction state will be exited and the normal monitoring frequency will be restored.

[0085] By employing the technical solution of this application embodiment, a frequency reduction detection strategy is executed when the number of consecutive occurrences of slow monitoring events reaches a threshold. This can adaptively reduce the monitoring frequency according to the continuous severity of the abnormal state of the storage device, effectively avoiding excessive consumption of background thread resources and flooding of log information when the device is continuously abnormal. This achieves refined management and utilization of monitoring resources while ensuring system stability.

[0086] In one feasible implementation, the preset recovery conditions include any of the following: the external storage device is detected to have been unplugged; the external storage volume is detected to have been remounted; or the task execution time is less than or equal to a first duration threshold.

[0087] In this embodiment, when the cumulative number of slow monitoring events reaches a threshold, the system enters a frequency reduction detection mode, reducing the frequency of submitting monitoring tasks to the underlying storage. However, the frequency reduction state should not be permanent; it also needs to have the ability to automatically sense the recovery of the storage device's state and exit the frequency reduction mode. Therefore, this embodiment presets a recovery condition to trigger the exit of the frequency reduction detection strategy. When any of these conditions is met, the system exits the frequency reduction state and resumes normal monitoring frequency.

[0088] Specifically, the preset recovery conditions include the following three scenarios. The first scenario is: An external storage device is detected as unplugged. When the watchdog management device detects that an external storage device has been unplugged by the user through a storage volume mount status monitoring mechanism (such as StorageManager's storage volume broadcast notification), it indicates that the physical media causing the slow monitoring has been removed, and storage monitoring is no longer needed. The watchdog management device will control the exit from the reduced frequency state, and monitoring will resume at a normal frequency after the device is reinserted. The second scenario is: An external storage volume is detected as remounted. When the watchdog management device detects that the storage volume has recovered from an abnormal state and has been successfully remounted, it indicates that the storage device may have returned to normal, and the watchdog management device will control the exit from the reduced frequency state. The third scenario is: The task execution time is less than or equal to a first duration threshold. In the reduced frequency state, monitoring tasks will still be executed at a lower frequency. If the execution time of a monitoring task falls back to within the first duration threshold, it indicates that the response performance of the storage device has returned to normal, and the watchdog management device will control the automatic exit from the reduced frequency state. By setting the recovery conditions described above, the watchdog management device can automatically resume normal monitoring after the anomaly is eliminated, ensuring continuous and effective observation of the storage status while conserving resources.

[0089] In this embodiment, by setting preset recovery conditions, the frequency reduction detection strategy is equipped with closed-loop management capabilities, realizing the automatic recovery of the monitoring frequency after the anomaly subsides, and improving the integrity and intelligence level of the system's adaptive adjustment mechanism.

[0090] In one feasible implementation, refer to Figure 3 The diagram illustrates a specific embodiment of a watchdog management method, which may include the following steps: Step S1: In response to the watchdog trigger, call the monitoring interface of the storage management service.

[0091] Specifically, when the watchdog mechanism reaches its periodic check process, the watchdog thread calls the monitor method of the registered storage management service (StorageManagerService). This call is initiated by the watchdog thread, and the current execution context is the system thread to which the watchdog belongs. After the monitoring interface is called, the monitoring process provided in this embodiment begins to execute.

[0092] Step S2: Obtain the underlying storage daemon object and determine whether the object is empty.

[0093] At the entry point of the monitoring interface, the operation of retrieving the underlying storage daemon object is performed first. In the Android system architecture, StorageManagerService internally maintains a reference to the Binder proxy object of the vold service. This retrieval operation is achieved by reading the vold service reference variable that has been established in StorageManagerService. If the storage service initialization has not been completed, or if the vold service has not started normally due to an exception, the value of this reference variable may be null. When the judgment result is that the underlying storage daemon object is null, it indicates that the current vold service is unavailable. At this time, any attempt to call the object's methods will fail, so the method flow jumps directly to step S6, and the monitoring interface returns immediately in the current thread without executing any subsequent operations. This null value check, as a pre-emptive protection, can effectively avoid null pointer exceptions caused by calling invalid object references, enhancing the robustness of the monitoring interface in the face of abnormal storage service states.

[0094] Step S3: When the underlying storage daemon object is not empty, read the atomic state variable and determine whether there is a monitoring task running.

[0095] When it is confirmed that the underlying storage daemon object is not empty, it indicates that the vold service is currently available. At this point, a pre-set atomic state variable is read. This atomic state variable is used to characterize whether there is already an underlying storage monitoring task running in the background executor. Specifically, the atomic state variable includes a first state and a second state. The first state (e.g., false) indicates that there is currently no running monitoring task, that is, the background executor is in an idle state, allowing the submission of new monitoring tasks; the second state (e.g., true) indicates that there is currently a running monitoring task, that is, there is already a monitoring task executing in the background executor, and no new monitoring tasks should be submitted at this time.

[0096] When the atomic state variable is currently in the second state (i.e., a task is already running), it indicates that the monitoring task submitted in the previous cycle has not yet been completed. At this time, the process jumps to step S6, the monitoring interface returns directly, and no new monitoring task is submitted. When the atomic state variable is currently in the first state (i.e., no task is running), it indicates that the conditions for submitting a new task are met, and the process proceeds to step S4.

[0097] Step S4: Set the atomic state variable to the second state and submit the monitoring task to the background executor.

[0098] When the atomic state variable is in state one, an atomic state variable switching operation is first performed to update it from state one to state two, marking that the existing monitoring task is about to start. This state switching operation should be performed atomically to ensure state consistency in a multi-threaded concurrent environment. Subsequently, the monitoring task of the underlying storage daemon is submitted to the background executor. The monitoring task involves calling the `monitor` method of the underlying storage daemon object, i.e., executing `vold.monitor`. After the task is submitted to the background executor, the background executor allocates an idle background thread from its managed thread pool to execute the monitoring task, while the current watchdog thread continues execution without waiting for the monitoring task to complete. Through this asynchronous processing, the monitoring task is executed in a new background thread, completely decoupled from the watchdog thread.

[0099] Step S5: Execute the monitoring task in a background thread and handle any exceptions during the execution process.

[0100] The monitoring task begins execution in a background thread, specifically by calling the `monitor` method of the underlying storage daemon to perform health checks on the external storage device. During execution, if an exception occurs, it is not propagated outwards. Instead, the exception is recorded internally in the background thread using a capture mechanism (such as a try-catch block). This recording includes, but is not limited to, outputting the exception type, exception message, and stack trace through the system log interface, facilitating subsequent problem diagnosis and fault location. After catching the exception, it is not re-thrown, thus preventing the exception event from being passed to the current thread calling the monitoring interface (i.e., the watchdog thread). Therefore, even if the underlying storage call throws an exception due to an external device malfunction, the exception will not propagate across threads to the watchdog thread, nor will it cause the watchdog thread to terminate abnormally due to receiving an uncaught exception. When the monitoring task completes normally (i.e., the `vold.monitor` call returns normally), there is no need to perform exception logging.

[0101] Step S6: Clean up the task status using the finally block and end the call to the monitoring interface.

[0102] Regardless of whether the monitoring task completes normally or throws an exception in step S5, a state recovery operation must ultimately be performed. This state cleanup is ensured using a `finally` block. Within the `finally` block, the atomic state variable is switched from the second state back to the first state to clear the flag indicating that a monitoring task is currently running. By placing the state recovery logic in the `finally` block, it is ensured that the atomic state variable can be reliably reset to the first state regardless of the reason for the monitoring task's termination (including normal completion, throwing an exception, or termination due to an error). After state cleanup is complete, the monitoring interface returns in the current watchdog thread, and the execution flow is handed back to the watchdog mechanism.

[0103] The technical solution adopted in this application switches the originally synchronous execution of underlying storage monitoring calls to asynchronous background execution. Combined with concurrency control of atomic state variables, null value prevention, and non-fatal exception handling, this allows the monitoring interface of the storage management service to return immediately after the watchdog call. This application separates the detection of the health status of external storage devices from the determination of the activity of core system services from the same execution path, ensuring that peripheral-level failures no longer affect system-level activity detection. Simultaneously, a finally block ensures the long-term sustainability of monitoring capabilities. This application fundamentally eliminates the risk of watchdog misjudgment and triggering an erroneous restart of the system_server process due to external storage device anomalies. While fully preserving the ability to continuously monitor the underlying storage status, it significantly improves the stability and robustness of the system when facing abnormal external storage devices, thus improving the user experience.

[0104] To facilitate better implementation of the watchdog management method of this application, this application also provides a watchdog management device based on the above-described watchdog management method. The meanings of the terms used are the same as in the watchdog management method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0105] Based on the same inventive concept, and referring to Figure 4 This application provides a watchdog management device 400, which includes: The object acquisition module 401 is used to obtain the underlying storage daemon object in response to the watchdog calling the monitoring interface of the storage management service in the current thread. The task submission module 402 is used to submit the monitoring task of the underlying storage daemon process to the background executor when the underlying storage daemon process object is not empty, so that the background executor can execute the monitoring task in the background thread and end the call to the monitoring interface.

[0106] In one embodiment, the task submission module 402 includes: The variable reading submodule is used to read atomic state variables. The atomic state variables include a first state and a second state. The first state indicates that there is no currently running monitoring task, and the second state indicates that there is currently a running monitoring task. The task submission submodule is used to submit the monitoring task of the underlying storage daemon to the background executor when the atomic state variable is in the first state, and to switch the atomic state variable from the first state to the second state; the watchdog management device 400 also includes: The task skip module is used to skip the submission of monitoring tasks to the background executor when the atomic state variable is in the second state, and the monitoring interface returns in the current thread.

[0107] In one embodiment, the watchdog management device 400 further includes: The state switching module is used to switch the atomic state variable from the second state to the first state in response to the completion of the monitoring task in the background thread.

[0108] In one embodiment, the watchdog management device 400 further includes: The exception logging module is used to respond to exception events that occur during the execution of monitoring tasks by the background executor, log the exception events, and prevent the exception events from being passed to the current thread.

[0109] In one embodiment, the watchdog management device 400 further includes: The time recording module is used to record the execution duration of monitoring tasks in a background thread; The event logging module is used to record slow monitoring events when the task execution time exceeds a first duration threshold. The frequency adjustment module is used to adjust the submission frequency of subsequent monitoring tasks based on the recorded information of slow monitoring events.

[0110] In one embodiment, the recorded information includes the cumulative number of consecutive slow monitoring events; the frequency adjustment module includes: The frequency reduction detection submodule is used to execute a frequency reduction detection strategy when the cumulative number of attempts reaches a threshold, until a preset recovery condition is met; the frequency reduction detection strategy includes: Within at least two watchdog cycles, submit the monitoring task only in one of the watchdog cycles; and / or, Get the end time of the last monitoring task completion or timeout, and skip submitting the monitoring task to the background executor if the time interval between the current time and the end time is less than the second duration threshold.

[0111] In one embodiment, the preset recovery conditions include any of the following conditions: External storage device detected has been removed; External storage volume remount detected; The task execution time is less than or equal to the first duration threshold.

[0112] The technical solution adopted in this application switches the originally synchronous execution of underlying storage monitoring calls to asynchronous background execution, enabling the monitoring interface of the storage management service to return immediately after being called by the watchdog. In this way, the watchdog mechanism can accurately distinguish between the deadlock state of the system service itself and the slow I / O state caused by peripheral devices, fundamentally eliminating the risk of watchdog misjudgment and triggering erroneous restarts of system service processes due to external storage device anomalies. Therefore, while fully retaining the ability to continuously monitor the underlying storage state, it significantly improves the stability and robustness of the system when facing abnormal external storage devices, thus improving the user experience.

[0113] Specific limitations regarding the watchdog management device 400 can be found in the limitations of the watchdog management method described above, and will not be repeated here. Each module in the watchdog management device 400 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0114] In addition, this application also provides an electronic device, such as Figure 5 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 501 with one or more processing cores and a memory 502 of one or more computer-readable storage media. Those skilled in the art will understand that... Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 501 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 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 501.

[0115] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 502 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 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0116] In one feasible implementation, the electronic device further includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0117] In one feasible implementation, the electronic device may further include an input unit 504, 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.

[0118] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 501 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 502 according to the following instructions, and the processor 501 runs the applications stored in the memory 502, thereby implementing the steps in any of the watchdog management methods provided in the embodiments of this application.

[0119] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0120] In one feasible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0121] In one feasible implementation, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods described in any embodiment of this application.

[0122] In one feasible implementation, a computer program product is also proposed, comprising a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

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

[0124] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0125] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the watchdog management methods provided in this application.

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

[0127] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0128] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the watchdog management methods provided in this application, the beneficial effects that any of the watchdog management methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0129] 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 said element.

[0130] The above provides a detailed description of a watchdog management method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples 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, those skilled in the art will recognize that 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 watchdog management method, characterized in that, The method includes: In response to the watchdog calling the monitoring interface of the storage management service in the current thread, the underlying storage daemon object is obtained; When the underlying storage daemon object is not empty, the monitoring task of the underlying storage daemon is submitted to the background executor so that the background executor executes the monitoring task in a background thread and terminates the call to the monitoring interface.

2. The watchdog management method according to claim 1, characterized in that, The step of submitting the monitoring task of the underlying storage daemon to the background executor includes: Read atomic state variables; the atomic state variables include a first state and a second state, the first state is used to indicate that there is currently no running monitoring task, and the second state is used to indicate that there is currently a running monitoring task; When the atomic state variable is in the first state, the monitoring task of the underlying storage daemon is submitted to the background executor, and the atomic state variable is switched from the first state to the second state; The method further includes: When the atomic state variable is in the second state, the submission of the monitoring task for the background executor is skipped, and the monitoring interface returns in the current thread.

3. The watchdog management method according to claim 2, characterized in that, The method further includes: In response to the completion of the monitoring task in the background thread, the atomic state variable is switched from the second state to the first state.

4. The watchdog management method according to claim 1, characterized in that, The method further includes: In response to detecting an abnormal event generated during the execution of the monitoring task by the background executor, the abnormal event is recorded and the transmission of the abnormal event to the current thread is prohibited.

5. The watchdog management method according to claim 1, characterized in that, The method further includes: The execution time of the monitoring task is recorded in the background thread; When the execution duration of the task exceeds a first duration threshold, a slow monitoring event is recorded; Based on the recorded information of the slow monitoring events, the submission frequency of subsequent monitoring tasks is adjusted.

6. The watchdog management method according to claim 5, characterized in that, The recorded information includes the cumulative number of times the slow monitoring event occurred consecutively; The adjustment of the submission frequency of subsequent monitoring tasks based on the recorded information of the slow monitoring events includes: When the cumulative number of attempts reaches a threshold, a frequency reduction detection strategy is executed until a preset recovery condition is met; wherein, the frequency reduction detection strategy includes: Within at least two watchdog cycles, the monitoring task is submitted only in one of the watchdog cycles; and / or, Obtain the end time of the last monitoring task completion or timeout, and skip submitting the monitoring task to the background executor if the time interval between the current time and the end time is less than a second duration threshold.

7. The watchdog management method according to claim 6, characterized in that, The preset recovery conditions include any of the following conditions: External storage device detected has been removed; External storage volume remount detected; The task execution time is less than or equal to the first time threshold.

8. A watchdog management device, characterized in that, The device includes: The object retrieval module is used to retrieve the underlying storage daemon object in response to the watchdog calling the monitoring interface of the storage management service in the current thread. The task submission module is used to submit the monitoring task of the underlying storage daemon process to the background executor when the underlying storage daemon process object is not empty, so that the background executor executes the monitoring task in a background thread and terminates the call to the monitoring interface.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the watchdog management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the watchdog management method as described in any one of claims 1 to 7.

Images