A service file processing method and electronic device

Abstract

The embodiment of the application discloses a kind of processing method and electronic equipment of service file, in the method, first, the target directed graph is constructed based on multiple services each corresponding service file, each service file includes the basic information of corresponding service and dependency information, which is used to indicate the dependency relationship of service and other service when starting.Second, the theoretical start order of multiple services based on target directed graph representation is compared with the actual start order of multiple services, to determine at least one target directed edge of start order problem, which is obtained after starting multiple services based on dependency information in multiple service files.Finally, according to at least one target directed edge, generate adjustment information, which is used to indicate the adjustment of service file of at least two target services constituting at least one target directed edge.Application of the method can efficiently and accurately adjust the service file, ensure the successful start of service and normal use.

Description

Technical Field

[0001] This application relates to the field of service management technology, and in particular to a method for processing service files and an electronic device. Background Technology

[0002] In a server management system, the Baseboard Management Controller (BMC) is responsible for starting and managing system services. System services have complex dependencies; if the startup order does not meet dependency requirements, service startup may fail or functionality may become unavailable, severely impacting system stability.

[0003] In related technologies, service configuration files are usually written manually, and then the validity and rationality of the service files are verified by manually checking the service configuration files and logs. However, this method relies heavily on human experience and is inefficient and prone to overlooking implicit dependency issues. Summary of the Invention

[0004] This application provides a service file processing method and an electronic device for efficiently and accurately adjusting service files, thereby ensuring successful service startup and normal function.

[0005] In a first aspect, one embodiment of this application provides a method for processing service files, including:

[0006] A target directed graph is constructed based on the service files corresponding to each of the multiple services. Each service file includes basic information and dependency information of the corresponding service. The dependency information is used to indicate the dependency relationship between the service and other services at startup. Each node of the target directed graph represents a service, and each directed edge of the target directed graph represents the dependency relationship between the two services that make up the directed edge.

[0007] The theoretical startup order of multiple services represented by the target directed graph is compared with the actual startup order of multiple services to identify at least one target directed edge where the startup order is problematic; wherein, the actual startup order is obtained by starting multiple services based on the dependency information in multiple service files.

[0008] Adjustment information is generated based on at least one target directed edge; wherein the adjustment information is used to instruct the service files of at least two target services constituting at least one target directed edge to be adjusted.

[0009] In this embodiment, each service file includes basic and dependency information for the corresponding service. This dependency information represents the dependency relationship between the service and other services at startup. Thus, in the target directed graph constructed based on the service files corresponding to multiple services, each node represents a service, and each directed edge represents the dependency relationship between the two services constituting that edge. Then, the theoretical startup order of the multiple services represented by the target directed graph is compared with the actual startup order. This allows for the identification of at least one target directed edge with a startup order problem, and the generation of adjustment information based on this edge. This adjustment information instructs adjustments to the service files of at least two target services constituting the at least one target directed edge. This design considers the dependencies between services, automatically, quickly, and efficiently generates adjustment information, and controls service startup based on the adjusted service files, ensuring normal service startup and operation.

[0010] In one optional implementation, a target directed graph is constructed based on the service files corresponding to each of the multiple services, including:

[0011] Construct an initial directed graph based on multiple service files;

[0012] Identify the closed-loop subgraph in the initial directed graph, and disconnect the reference directed edge formed by any two nodes among the multiple nodes that constitute the closed-loop subgraph to obtain the target directed graph.

[0013] In this embodiment of the application, since a closed-loop subgraph can lead to cyclic dependencies, making sorting infeasible, the reference directed edge formed by any two nodes among the multiple nodes constituting the closed-loop subgraph can be disconnected to break the cyclic dependencies. In this way, a topological sorting operation can be performed on the initial directed graph to obtain the target directed graph.

[0014] In one alternative implementation, an initial directed graph is constructed based on multiple service files, including:

[0015] For each service file, extract the strong dependency information and weak dependency information of the service file; where strong dependency information is used to indicate the first other service that has a strong dependency relationship with the service file corresponding to the service file, and weak dependency information is used to indicate the second other service that has a weak dependency relationship with the service file corresponding to the service file; strong dependency relationship means that the start time of the service is less than or greater than the start time of the first other service, and weak dependency relationship means that the time difference between the start time of the service and the start time of the second other service is less than a set time range.

[0016] Construct an initial directed graph based on the strong and weak dependency information of each service file.

[0017] In this embodiment of the application, considering that different dependencies may lead to different ways of generating adjustment information or adjusting service files based on the adjustment information, the dependencies are subdivided during the construction of the initial directed graph. Strong and weak dependency information in each service file can be extracted, and then the corresponding strong and weak dependencies can be combined to construct the initial directed graph.

[0018] In one alternative implementation, the method further includes:

[0019] For any target directed edge, if the services represented by the two nodes constituting the target directed edge have a strong dependency relationship, an alarm message is generated; if the services represented by the two nodes constituting the target directed edge have a weak dependency relationship, an optimization suggestion is generated; the alarm message carries information about the target directed edge.

[0020] In this embodiment of the application, different processing suggestions can be generated for strong and weak dependencies, and service files can be adjusted in a targeted manner.

[0021] In one alternative implementation, adjustment information is generated based on at least one target directed edge, including:

[0022] The problem type that determines at least one directed edge with a target;

[0023] Adjustment information is generated based on the problem type, the risk levels of the service files corresponding to at least two target services that constitute at least one target directed edge, and the service files corresponding to the two services that constitute a reference directed edge; wherein, the risk level of each service file is determined after applying an inspection command to check the compliance of each service file.

[0024] In this embodiment of the application, the generated adjustment information includes not only the problem type of the problematic directed edge of the target, but also the risk level of the target service corresponding to the directed edge of the target. This results in more comprehensive adjustment information, which allows for more comprehensive adjustment of the service file.

[0025] In one optional implementation, the theoretical startup order of multiple services represented by the target directed graph is compared with the actual startup order of the multiple services to determine at least one target directed edge where the startup order has a problem, including:

[0026] Based on the target directed graph, multiple dependency chains are determined; each dependency chain consists of multiple directed edges composed of multiple nodes, and the services represented by each of the multiple nodes constitute a complete function.

[0027] For each dependency chain, based on the theoretical startup order of the services represented by multiple nodes, search within the actual startup order to identify at least one target directed edge in the dependency chain that differs from the actual startup order.

[0028] In this embodiment of the application, during the comparison of the theoretical startup order and the actual startup order, the comparison can be performed on a dependency chain basis, which can improve the comparison efficiency and quickly identify the problematic target directed edges.

[0029] In one alternative implementation, the method further includes:

[0030] Display the target directed graph and highlight the target directed edges in the target directed graph.

[0031] In this embodiment of the application, the problematic directed edges are visualized, making it easier for users to quickly identify the target directed edges.

[0032] In one alternative implementation, the method further includes:

[0033] In response to a user's viewing action, highlight the nodes corresponding to services that depend on the first service indicated by the viewing action.

[0034] In response to the user's filtering action, highlight the directed edge indicating the filtering action.

[0035] In this embodiment of the application, under the condition of visualization, not only can the desired node be viewed, but also the desired directed edge can be viewed, which can assist the user in performing other operations.

[0036] In one alternative implementation, the service is a plurality of system services controlled and executed by the baseboard management controller.

[0037] Secondly, one embodiment of this application provides a service file processing apparatus, including:

[0038] A directed graph construction unit is used to: construct a target directed graph based on the service files corresponding to multiple services; wherein, each service file includes basic information and dependency information of the corresponding service, the dependency information is used to indicate the dependency relationship between the service and other services at startup, each node of the target directed graph represents a service, and each directed edge of the target directed graph represents the dependency relationship between the two services that constitute the directed edge;

[0039] The problem determination unit is used to: compare the theoretical startup order of multiple services represented by the target directed graph with the actual startup order of the multiple services, and determine at least one target directed edge where the startup order has a problem; wherein, the actual startup order is obtained after starting multiple services based on the dependency information in multiple service files;

[0040] An adjustment unit is configured to: generate adjustment information based on at least one target directed edge; wherein the adjustment information is used to instruct the service files of at least two target services constituting at least one target directed edge to be adjusted.

[0041] Thirdly, one embodiment of this application provides an electronic device, including 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 any of the above methods.

[0042] Fourthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0043] Fifthly, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods. Attached Figure Description

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

[0045] Figure 1 An architecture diagram of a service file processing system provided in one embodiment of this application;

[0046] Figure 2 A flowchart illustrating a method for processing service files according to an embodiment of this application;

[0047] Figure 3 A schematic diagram illustrating the visualization of a target directed graph provided in one embodiment of this application;

[0048] Figure 4 A visual schematic diagram of another target-directed graph provided in an embodiment of this application;

[0049] Figure 5 A flowchart illustrating a complete service file processing method provided in one embodiment of this application;

[0050] Figure 6 A schematic diagram of a service file processing apparatus provided in an embodiment of this application;

[0051] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0053] For ease of understanding, the terms used in the embodiments of this application are explained below:

[0054] (1) The baseboard management controller is a chip embedded on the computer motherboard for remote management and monitoring of the hardware status of devices such as servers.

[0055] (2) systemd, short for system daemon, is a commonly used init software in Linux. It is used to represent the dependencies between system services and thereby enable the parallel startup of services during system initialization.

[0056] (3) Graphviz graphviz is an open-source toolkit for drawing graphs described by Graph Description Language (DOT) scripts.

[0057] (4) NetworkX is a Python library for complex network analysis, specifically designed for creating, manipulating and studying the topological and dynamic properties of graph structures.

[0058] (5) Tkinter Tkinter is Python's standard graphical user interface (GUI) toolkit, providing cross-platform window components and interactive features.

[0059] The number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0060] In server management systems, the baseboard management controller is responsible for starting and managing system services. System services have complex dependencies; if the startup order does not meet dependency requirements, service startup may fail or functionality may become unavailable, severely impacting system stability. Traditional verification methods rely on manually writing and checking service configuration files and logs, which is essentially a one-dimensional check, inefficient, and prone to overlooking hidden dependency issues. These drawbacks are even more pronounced in cloud computing and directed edge computing scenarios, where service dynamism is enhanced.

[0061] In related technologies, the validity of service files is typically verified manually using basic dependency analysis tools. Systemd-analyze, a tool included with Linux systems, provides statistics on basic service startup times and dependency trees. However, it only statically displays dependencies and cannot dynamically detect conflicts between the actual startup order and theoretical dependencies, and it lacks interactive visualization capabilities. Furthermore, during manual verification, the startup order and dependencies of system services are primarily verified manually using the aforementioned systemd-analyze tool. Testers need to examine the configuration files of each service in the tool's output, understand their dependencies, and manually record and analyze them. This process may depend on specific systemd versions or require the installation of third-party tools (such as systemd-cgls).

[0062] Therefore, the following problems with the aforementioned technologies can be illustrated with specific examples:

[0063] (1) The verification efficiency is low.

[0064] For example, a server system typically hosts 150+ systemd service units, each storing a service file used to start a service. Of these services, 30% have implicit dependencies. In related technologies, manual verification takes an average of 4-6 hours per instance. Verifying actual service startup sequence issues requires manually cross-referencing the timestamps of journalctl logs with the systemd-analyze tool results, which takes an average of over 2 hours per instance. Furthermore, systemd-analyze only outputs raw logs; tracing dependency chains requires manual, layer-by-layer investigation, which is time-consuming and prone to omissions.

[0065] The main reasons for the low verification efficiency include the lack of automated toolchains and scattered logs. Regarding the lack of automated toolchains, the systemd ecosystem does not provide a module for correlation analysis of dependencies and time series; regarding scattered logs, timestamps and dependencies (unit files) are stored in different subsystems.

[0066] (2) Lack of dynamic verification capability.

[0067] Tools in related technologies only perform static analysis of the syntax of service configuration files, without verifying the effectiveness of dependencies in conjunction with the actual startup sequence. In some cases, the theoretical dependencies declared in the service configuration file may fail due to service startup timeouts, resource contention (such as CPU preemption), kernel scheduling delays, etc., all of which can cause service malfunctions. Therefore, related technologies can only detect static configuration errors (such as file permission issues) and cannot detect runtime dependency conflicts (such as circular dependencies), or, when circular dependencies are detected, they simply exit with an error message without providing any repair suggestions.

[0068] The reasons for the lack of dynamic verification capabilities are as follows: the systemd architecture separates configuration parsing from the runtime state machine, making it impossible for static analysis to perceive dynamic behavior; dependency verification only occurs during the service loading phase and does not cover the entire lifecycle.

[0069] (3) Output format readability defects.

[0070] The output of tools in related technologies is usually in plain text format. When the dependency level exceeds 5 levels, the readability drops sharply, and it is difficult to understand the implicit dependencies or the difference between strong and weak dependencies when manually checking.

[0071] The main reasons for the readability defects in the output format include: DOT language being a general-purpose graphical description language, lacking domain-specific optimization, and missing key information.

[0072] (4) Visual interaction defects.

[0073] Tools in related technologies rely on the Graphviz package to convert DOT text into static images. However, when the number of dependency graph nodes exceeds 100, the generated images exhibit a chaotic layout, intersecting lines, and an inability to highlight critical paths or conflicting dependencies, making it difficult for users to quickly and clearly identify problematic items. Dependencies are displayed as text or simple DOT diagrams, lacking interactive troubleshooting capabilities (such as systemd-analyze plots).

[0074] To address this, this application provides a method for processing service files, enabling intelligent verification of system service startup order and dependencies. Specifically, by remotely connecting to a server, it analyzes service dependencies, generates a service dependency topology diagram, extracts the actual startup sequence, cross-compares the theoretical dependency order with the actual startup order, identifies potential risks, and provides a visual representation through a graphical interface to assist in quickly troubleshooting and fixing problems.

[0075] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0076] refer to Figure 1 This is an architecture diagram of a service file processing system provided in an embodiment of this application. This system architecture diagram can optimize and detect system service startup based on dynamic dependency analysis and timing verification. The architecture includes a remote service acquisition layer, a compliance verification module, a timing comparison engine, and a visualization interaction layer.

[0077] The remote service acquisition layer utilizes a multi-threaded connection pool based on the Paramiko library to parallelize command execution on the BMC, collecting service configuration, dependency relationships, and startup timestamp data. The dependency modeling engine parses After / Before / Requires syntax in service configuration files, constructing a directed graph model (nx.DiGraph) to distinguish between strong and weak dependencies. The compliance verification module automatically categorizes 12 types of issues in service files, such as permission errors, path errors, and dependency conflicts, based on regular expression patterns (predefined rule sets in re.compile). The time-series comparison engine uses systemctlshow to obtain the actual service startup timestamp, compares it with the theoretical topology sorting results, and identifies order conflicts and circular dependencies. The visualization and interaction layer uses NetworkX and Matplotlib / Tkinter to construct a dynamic and interactive dependency graph, supporting node focusing, error highlighting, and dependency chain tracing.

[0078] The application scenarios of this application include, but are not limited to: for released BMC or general Linux platforms, service startup order and compliance verification can be performed to replace manual testing and save labor costs; in continuous integration or continuous delivery pipelines, lightweight scripts can support error interception in the pre-release stage to reduce errors from flowing into the production department.

[0079] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application does not impose any limitations. Figure 1 The functions that each device in the application scenario shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here.

[0080] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0081] The following is combined with Figure 1 The application scenarios shown illustrate the technical solutions provided in the embodiments of this application.

[0082] refer to Figure 2 This application provides a method for processing service files, applied to an electronic device, which may be a BMC (Browser Management System). The method includes the following steps:

[0083] S201: Construct a target directed graph based on the service files corresponding to each of the multiple services.

[0084] S202: Based on the theoretical startup order of multiple services represented by the target directed graph, compare it with the actual startup order of multiple services to determine at least one target directed edge where the startup order has a problem.

[0085] S203: Generate adjustment information based on at least one target directed edge.

[0086] In this embodiment, each service file includes basic and dependency information for the corresponding service. This dependency information represents the dependency relationship between the service and other services at startup. Thus, in the target directed graph constructed based on the service files corresponding to multiple services, each node represents a service, and each directed edge represents the dependency relationship between the two services constituting that edge. Then, the theoretical startup order of the multiple services represented by the target directed graph is compared with the actual startup order. This allows for the identification of at least one target directed edge with a startup order problem, and the generation of adjustment information based on this edge. This adjustment information instructs adjustments to the service files of at least two target services constituting the at least one target directed edge. This design considers the dependencies between services, automatically, quickly, and efficiently generates adjustment information, and controls service startup based on the adjusted service files, ensuring normal service startup and operation.

[0087] Regarding S201, each service file includes basic information and dependency information for the corresponding service. The basic information may include the service name, service function, and service identifier, while the dependency information is used to indicate the service's dependencies on other services at startup.

[0088] In this embodiment of the application, a target directed graph can be constructed based on the service files corresponding to multiple services. Each node in the target directed graph represents a service, and each directed edge in the target directed graph represents the dependency relationship between the two services that constitute the directed edge.

[0089] Optionally, the process of constructing the target directed graph can be illustrated through steps A1-A2:

[0090] A1: Construct an initial directed graph based on multiple service files.

[0091] This process can be achieved through steps A1-1 to A1-2:

[0092] A1-1: For each service file, extract the strong dependency information and weak dependency information of that service file.

[0093] Strong dependency information indicates a first other service that has a strong dependency relationship with the service corresponding to the service file, while weak dependency information indicates a second other service that has a weak dependency relationship with the service corresponding to the service file. A strong dependency relationship means that the startup time of the service is less than or greater than the startup time of the first other service, while a weak dependency relationship means that the time difference between the startup time of the service and the startup time of the second other service is less than a set time range.

[0094] In other words, a strong dependency means that there is a clear order of startup between the two services. For example, service A must start before service B, otherwise service B cannot start. A weak dependency means that the two services can start as long as the time difference between their startup times is within a set time range.

[0095] A1-2: Construct an initial directed graph based on the strong and weak dependency information of each service file.

[0096] Optionally, a directed graph can be used for modeling based on dependencies, where each node represents an independent service and the directed edges between nodes represent dependencies. For example, if there is a directed edge A→B, it means that service B depends on the startup and completion of service A.

[0097] In this embodiment of the application, strong-dependent directed edges and weak-dependent directed edges are distinguished during the generation of the initial directed graph, and different processing logics can be used in the subsequent detection process.

[0098] A2: Identify the closed-loop subgraph in the initial directed graph, and disconnect the reference directed edge formed by any two nodes among the multiple nodes that constitute the closed-loop subgraph to obtain the target directed graph.

[0099] After obtaining the initial directed graph, a topological sorting operation can be performed to check its ordering. During the sorting process, if circular dependencies lead to the existence of closed subgraphs, and these closed subgraphs make sorting infeasible (e.g., by catching the NetworkXUnfeasible exception), conflicting directed edges forming closed loops can be automatically removed. For example, the conflicting directed edges formed by any two nodes in a closed subgraph can be disconnected (represented as reference directed edges for distinction), and the initial directed graph can be updated to obtain the target directed graph. Furthermore, for subsequent source tracing analysis, the source files and corresponding line numbers of the conflicting directed edges can be recorded.

[0100] This application's embodiments effectively solve the problem of difficult detection and location of circular dependencies in traditional service dependency analysis by performing a topology sorting operation. By dynamically detecting and removing conflicting directed edges, the final generated theoretical startup order is ensured to be executable, laying the foundation for subsequent startup sequence verification. This mechanism improves the reliability of dependency modeling and avoids the risk of system initialization failure due to dependency loops.

[0101] Regarding S202, after obtaining the target directed graph, the theoretical startup order of the multiple services it represents can be determined. In order to determine at least one target directed edge where the startup order is problematic, multiple services can be started based on the dependency information in multiple service files to determine the actual startup order, and then compared.

[0102] Optionally, the ExecMainStartTimestamp and ExecMainExitTimestamp properties of each service unit within the server can be remotely queried in batches via an automated method to extract the actual startup time data and determine the actual startup order.

[0103] The comparison process can be achieved through steps B1-B2:

[0104] B1: Based on the target directed graph, determine multiple dependency chains.

[0105] Each dependency chain consists of multiple directed edges formed by multiple nodes. The services represented by each node constitute a complete function. For example, an execution chain can be composed of a root node and its child nodes up to the leaf nodes.

[0106] B2: For the theoretical startup order of services represented by multiple nodes in each dependency chain, search within the actual startup order to identify at least one target directed edge in the dependency chain that differs from the actual startup order.

[0107] For any target directed edge, if the services represented by the two nodes constituting the target directed edge have a strong dependency relationship, an alarm message is generated; if the services represented by the two nodes constituting the target directed edge have a weak dependency relationship, an optimization suggestion is generated; the alarm message carries information about the target directed edge.

[0108] For example, if a strong dependency (such as service A should start before service B) is detected to be violated during actual startup (i.e., service A starts later than service B), the dependency chain is recorded and a severe alert with detailed traceability information is generated. For weak dependencies, it checks whether the related services start synchronously or close to each other. If there is a significant deviation in startup time, optimization suggestions are generated.

[0109] In S203, after the comparison is completed, adjustment information is generated based on at least one target directed edge. This adjustment information is used to instruct the service files of at least two target services that constitute at least one target directed edge to be adjusted.

[0110] Optionally, this process can be achieved through steps C1-C2:

[0111] C1: Problem type that determines at least one directed edge with a target;

[0112] C2: Generate adjustment information based on the problem type, the risk level of the service files corresponding to the at least two target services that constitute at least one target directed edge, and the service files corresponding to the two services that constitute the reference directed edge.

[0113] The risk level of each service file is determined by applying inspection commands to check the compliance of each service file.

[0114] Optionally, during compliance checks, the `systemd-analyze verify` command can be invoked to remotely batch execute all systemd service unit files within the server. The returned raw error messages are then matched and categorized item by item using 11 predefined regular expression patterns. After categorization, the system outputs the results in a structured format and assigns different severity levels based on the problem type.

[0115] This application's embodiment, through compliance checks, can automatically achieve efficient and systematic compliance verification of a large number of service files. Compared to the traditional method of relying on manual line-by-line log review, it greatly improves the speed and accuracy of error detection. Furthermore, through risk classification, it helps operations and maintenance personnel prioritize the handling of critical configuration errors, reducing potential risks during service deployment and operation.

[0116] This application's embodiments can accurately reveal hidden service contention issues, dependency latency issues, or unreasonable configuration issues during server startup. It not only achieves consistency verification between theoretical models and actual behavior but also provides quantitative data support for optimizing system startup efficiency and reducing service dependency anomalies.

[0117] Furthermore, based on the aforementioned technical solution, a graphical user interface (GUI) based on Tkinter was constructed using the ServiceGraphApp class. Within this interface, users can utilize the following interactive operations to assist in locating problems: directly displaying the target directed graph; highlighting target directed edges within the target directed graph; automatically highlighting its direct dependencies by clicking on any node in the target directed graph; or quickly filtering and focusing on specific service dependency chains by searching for the service name in the input box. For detected abnormal directed edges, the system highlights them in red, making the problem location visually apparent.

[0118] In a specific example Figure 3 This is a schematic diagram illustrating the visualization of a target directed graph provided in an embodiment of this application. Figure 3 The dependencies between services A, B, C, D, E, and F are shown. Figure 4 This is a visualization diagram of another target-directed graph provided in an embodiment of this application. Figure 4 The dependencies between services G, H, I, J, and L are illustrated, where the directed edge between services H and J is the target directed edge with an problematic startup order. Figure 4 The text can be displayed using dashed lines or different colors. It should be noted that... Figure 4 The starting order of the directed edges of the target shown is the theoretical starting order and does not represent the actual starting order.

[0119] This application's embodiments can display the complex service dependencies within a server in a visual and interactive manner, significantly reducing the difficulty for operations and maintenance personnel to understand the system startup logic. Simultaneously, the graphical interface intuitively identifies abnormal dependencies, greatly accelerating the problem localization and repair process, and improving overall operations and maintenance response speed and efficiency.

[0120] In summary, this application's embodiments improve analysis accuracy by using dynamic topology sorting and timestamp verification to cover both static configuration and runtime order conflicts; automated dependency chain tracing directly marks the conflict source service and configuration file location, improving problem localization efficiency; an interactive graph is provided, supporting click-focusing, error highlighting, and weak dependency filtering, enhancing visualization capabilities; based on the Secure Shell (SSH) protocol's universal interface, it is compatible with Linux distributions' systemd implementations (based on paramiko library calls), improving compatibility; and by stripping conflicting directed edges, it automatically generates feasible startup sequences, improving self-healing capabilities.

[0121] Figure 5 A flowchart illustrating a complete service file processing method provided in this application embodiment. Figure 5 It should include at least the following steps:

[0122] S501: For each service file, extract the strong dependency information and weak dependency information of the service file.

[0123] S502: Construct an initial directed graph based on the strong and weak dependency information of each service file.

[0124] S503: Identify the closed-loop subgraph in the initial directed graph, and disconnect the reference directed edge formed by any two nodes among the multiple nodes that constitute the closed-loop subgraph to obtain the target directed graph.

[0125] S504: Based on the target directed graph, determine multiple dependency chains; where each dependency chain consists of multiple directed edges composed of multiple nodes, and the services represented by each of the multiple nodes constitute a complete function.

[0126] S505: For the theoretical startup order of services represented by multiple nodes in each dependency chain, search within the actual startup order to determine at least one target directed edge in the dependency chain that differs from the actual startup order.

[0127] S506: The problem type that determines at least one directed edge with a target.

[0128] S507: Generate adjustment information based on the problem type, the risk level of the service files corresponding to the at least two target services that constitute at least one target directed edge, and the service files corresponding to the two services that constitute the reference directed edge.

[0129] S508: Display the target directed graph and highlight the target directed edges in the target directed graph.

[0130] The specific execution process of each step can be found in the aforementioned embodiments, and will not be repeated here.

[0131] This application combines topology sorting, timing verification, and interactive visualization for systemd service analysis. Compared to existing tools (such as systemd-analyze) that can only detect single-layer issues, it enables cross-layer dependency chain tracing. Furthermore, SSH connection pooling and regular expression pre-compilation ensure performance for large-scale deployments.

[0132] In addition, the beneficial effects of the embodiments of this application can be explained from the perspective of specific data:

[0133] By employing dual verification of strong and weak dependencies, the exposure rate of hidden startup competition issues (such as service B timeout due to delayed startup of service A) undetected in related technologies is increased from <30% to 98%; startup reliability is improved by over 90%. The time required for traditional manual troubleshooting is reduced from 2-4 hours to within 5 minutes, saving time in problem localization. The compliance verification module's 11 rule sets improve the completeness of configuration error repair to 100%, increasing the error repair rate and improving overall operational efficiency by 10 times. Compared to related technologies that require continuous running of monitoring processes (such as journalctl-f), this application only collects data momentarily during the startup phase (SSH connection pool reuse technology), offering a lightweight advantage; memory usage is reduced from over 200MB in traditional tools to below 50MB, reducing resource consumption by 70%.

[0134] like Figure 6 As shown, based on the same inventive concept as the above-described service file processing method, this application embodiment also provides a service file processing apparatus, including a directed graph construction unit 61, a problem determination unit 62, and an adjustment unit 63.

[0135] The directed graph construction unit 61 is used to: construct a target directed graph based on the service files corresponding to multiple services; wherein each service file includes basic information and dependency information of the corresponding service, the dependency information is used to indicate the dependency relationship between the service and other services at startup, each node of the target directed graph represents a service, and each directed edge of the target directed graph represents the dependency relationship between the two services that constitute the directed edge.

[0136] Problem determination unit 62 is used to: compare the theoretical startup order of multiple services represented by the target directed graph with the actual startup order of multiple services, and determine at least one target directed edge where the startup order has a problem; wherein, the actual startup order is obtained after starting multiple services based on the dependency information in multiple service files;

[0137] The adjustment unit 63 is configured to: generate adjustment information based on at least one target directed edge; wherein the adjustment information is used to instruct the service files of at least two target services constituting at least one target directed edge to be adjusted.

[0138] In one alternative implementation, the directed graph construction unit 61 is specifically used for:

[0139] Construct an initial directed graph based on multiple service files;

[0140] Identify the closed-loop subgraph in the initial directed graph, and disconnect the reference directed edge formed by any two nodes among the multiple nodes that constitute the closed-loop subgraph to obtain the target directed graph.

[0141] In one alternative implementation, the directed graph construction unit 61 is specifically used for:

[0142] For each service file, extract the strong dependency information and weak dependency information of the service file; where strong dependency information is used to indicate the first other service that has a strong dependency relationship with the service file corresponding to the service file, and weak dependency information is used to indicate the second other service that has a weak dependency relationship with the service file corresponding to the service file; strong dependency relationship means that the start time of the service is less than or greater than the start time of the first other service, and weak dependency relationship means that the time difference between the start time of the service and the start time of the second other service is less than a set time range.

[0143] Construct an initial directed graph based on the strong and weak dependency information of each service file.

[0144] In an alternative implementation, the directed graph construction unit 61 is further configured to:

[0145] For any target directed edge, if the services represented by the two nodes constituting the target directed edge have a strong dependency relationship, an alarm message is generated; if the services represented by the two nodes constituting the target directed edge have a weak dependency relationship, an optimization suggestion is generated; the alarm message carries information about the target directed edge.

[0146] In one alternative implementation, the adjustment unit 63 is specifically used for:

[0147] The problem type that determines at least one directed edge with a target;

[0148] Adjustment information is generated based on the problem type, the risk levels of the service files corresponding to at least two target services that constitute at least one target directed edge, and the service files corresponding to the two services that constitute a reference directed edge; wherein, the risk level of each service file is determined after applying an inspection command to check the compliance of each service file.

[0149] In an alternative implementation, the problem determination unit 62:

[0150] Based on the target directed graph, multiple dependency chains are determined; each dependency chain consists of multiple directed edges composed of multiple nodes, and the services represented by each of the multiple nodes constitute a complete function.

[0151] For each dependency chain, based on the theoretical startup order of the services represented by multiple nodes, search within the actual startup order to identify at least one target directed edge in the dependency chain that differs from the actual startup order.

[0152] In an optional implementation, a display unit is further included, for:

[0153] Display the target directed graph and highlight the target directed edges in the target directed graph.

[0154] In one alternative implementation, the display unit is further configured to:

[0155] In response to a user's viewing action, highlight the nodes corresponding to services that depend on the first service indicated by the viewing action.

[0156] In response to the user's filtering action, highlight the directed edge indicating the filtering action.

[0157] In one alternative implementation, the service is a plurality of system services controlled and executed by the baseboard management controller.

[0158] The service file processing apparatus proposed in this application embodiment adopts the same inventive concept as the above-described service file processing method and can achieve the same beneficial effects, so it will not be described again here.

[0159] Based on the same inventive concept as the above-mentioned service file processing method, this application also provides an electronic device, which may specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), server, etc. Figure 7 As shown, the electronic device may include a processor 701 and a memory 702.

[0160] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0161] Memory 702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 702 in the embodiments of this application may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0162] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0163] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), and other media capable of storing program code.

[0164] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the service file processing methods described above. Since the principle by which the above computer program product solves the problem is similar to that of the service file processing method, the implementation of the above computer program product can be referred to the implementation of the method, and repeated details will not be repeated.

[0165] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for processing service files, characterized in that, include: For each service file, strong dependency information and weak dependency information are extracted. Each service file includes basic information and dependency information for the corresponding service. The dependency information indicates the dependency relationship between the service and other services at startup. The strong dependency information indicates a first other service that has a strong dependency relationship with the service corresponding to the service file, and the weak dependency information indicates a second other service that has a weak dependency relationship with the service corresponding to the service file. The strong dependency relationship indicates that the startup time of the service is less than or greater than the startup time of the first other service, and the weak dependency relationship indicates that the time difference between the startup time of the service and the startup time of the second other service is less than a set time range. Construct an initial directed graph based on the strong dependency information and weak dependency information corresponding to each service file; Identify the closed-loop subgraph in the initial directed graph and disconnect the reference directed edge formed by any two nodes among the multiple nodes constituting the closed-loop subgraph to obtain the target directed graph; wherein, each node in the target directed graph represents a service, and each directed edge in the target directed graph represents the dependency relationship between the two services constituting the directed edge. Based on the theoretical startup order of multiple services represented by the target directed graph, the actual startup order of the multiple services is compared with the actual startup order to identify at least one target directed edge where the startup order has a problem; wherein, the actual startup order is obtained after starting the multiple services based on the dependency information in the multiple service files; Adjustment information is generated based on the at least one target directed edge; wherein the adjustment information is used to indicate adjustments to the service files of at least two target services constituting the at least one target directed edge.

2. The method according to claim 1, characterized in that, The method further includes: For any given target directed edge, if the services represented by the two nodes constituting the target directed edge have a strong dependency relationship, an alarm message is generated; if the services represented by the two nodes constituting the target directed edge have a weak dependency relationship, an optimization suggestion is generated; wherein, the alarm message carries information about the target directed edge.

3. The method according to claim 1, characterized in that, The step of generating adjustment information based on the at least one target directed edge includes: The problem type for determining the at least one directed edge with a target; Adjustment information is generated based on the problem type, the risk levels of the service files corresponding to the at least two target services constituting the at least one target directed edge, and the service files corresponding to the two services constituting the reference directed edge; wherein, the risk level of each service file is determined after applying an inspection command to check the compliance of each service file.

4. The method according to claim 1, characterized in that, The theoretical startup order of the multiple services represented by the target directed graph is compared with the actual startup order of the multiple services to determine at least one target directed edge where the startup order has a problem, including: Based on the target directed graph, multiple dependency chains are determined; wherein each dependency chain consists of multiple directed edges composed of multiple nodes, and the services represented by each of the multiple nodes constitute a complete function. For each dependency chain, based on the theoretical startup order of the services represented by the multiple nodes, a search is performed in the actual startup order to determine at least one target directed edge in the dependency chain that differs from the actual startup order.

5. The method according to claim 1, characterized in that, The method further includes: Display the target directed graph and highlight the target directed edges in the target directed graph.

6. The method according to claim 5, characterized in that, The method further includes: In response to a user's viewing action, the nodes corresponding to services that have a dependency relationship with the first service indicated by the viewing action are highlighted; In response to the user's filtering action, the directed edge indicated by the filtering action is highlighted.

7. The method according to any one of claims 1 to 6, characterized in that, The services are multiple system services controlled and executed by the baseboard management controller.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images