CN107623581B

CN107623581B - Service list generation method, device and system, and acquisition and reporting method and device

Info

Publication number: CN107623581B
Application number: CN201610560803.1A
Authority: CN
Inventors: 袁明敏
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-07-15
Filing date: 2016-07-15
Publication date: 2020-11-24
Anticipated expiration: 2036-07-15
Also published as: CN107623581A

Abstract

The invention discloses a service list generation method, a service list generation device and a service list generation system, and an acquisition and reporting method and device. Wherein, the method comprises the following steps: receiving a request message from a first terminal, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by a server; determining script file identifications of partial or all initialization types of one or more second terminals; determining process identifications corresponding to part or all of the script file identifications of the initialization type; generating a service list according to the determined script file identifier and the process identifier; and sending the service list to the first terminal. The invention solves the technical problem that the automatic management of the Linux service can not be realized because the mutual matching between the service list and the process list can not be realized in the related technology.

Description

Service list generation method, device and system, and acquisition and reporting method and device

Technical Field

The invention relates to the field of computers, in particular to a service list generation method, a service list generation device and a service list generation system, and an acquisition and reporting method and device.

Background

The Linux service is similar to windows application program, and usually exists in a form of daemon process, and provides corresponding functions for Linux users. For example, Secure SHell Daemon (SSHD) service, which provides a service for users to log in and execute Linux commands remotely. The Secure SHell (SSH) is a protocol that provides Secure telnet and other Secure network services over an insecure network. SSH can be divided into a client part and a service part. The server is a Daemon process (Daemon) that runs in the background and responds to connection requests from clients. The server side, typically an SSHD process, may provide handling of remote connections, including but not limited to: public key authentication, key exchange, symmetric keys, and insecure connections. Clients may include SSH programs as well as other applications such as remote copy (scp), telnet (slogin), secure file transfer (sftp), and the like.

In the currently mainstream Linux operating system, the information of the services and the start script are maintained under a preset directory name (e.g.: etc/init. d /), and a service (service) command is provided to manage the services, wherein each service may have only one process or a plurality of different processes. The mainstream Linux operating system provides a service operating framework, which may include but is not limited to: a start script for the service, an executable program. The start script of the service is usually managed under the/etc/init.d/directory using the service command. In a general case, the service command requires a start script to provide a start service (start), a stop service (stop), a restart service (restart), and a view status (status) parameter interface, respectively.

However, the management method using the service command has many defects, and due to the open source, the writing of the service script does not strictly follow a specific set of rules, thereby easily resulting in the lack of a fixed format for the service command, such as: if the user needs to check the state of the service A, the user writes a service A status service script, and the result may return to the service A is stopped; if the user needs to view the state of service B, the user has written a service B status service script, the result of which may be returned to service B is not running. These differences in return formats greatly increase the difficulty of automated service management and may not accurately locate the start-stop state of the service. Furthermore, existing service management tools lack a solution for obtaining and presenting performance overhead data that can provide services, such as: the method comprises the steps of obtaining a Central Processing Unit (CPU), a memory, a disk and network traffic of a service, wherein the data are very important for management and abnormal monitoring of daily service. Moreover, existing tools for service management are typically developed based on service and command line run level set (chkconfig) commands, such as: service management in a WDlinux Control Panel (WDCP) may acquire whether a service is self-started through a chkconfig command, operate start/stop of the service through a service command, and determine a state of the service. However, it has been shown that in the course of actual use, the service state in the WDCP is difficult to be accurately acquired.

The following is a conventional flow for starting/closing service in Linux service management, and specifically comprises the following steps:

firstly, acquiring a service identifier list through an/etc/init.d/directory;

secondly, for each service identifier xxx in the service identifier list, operating a service state viewing command service xxx status, viewing whether the return value contains the contents of run or stop and the like, and further judging whether the service is started successfully;

thirdly, using a start/close service command service xxx start/stop to start or close service;

and fourthly, judging whether the service is started successfully or not by using the service xxx status again.

However, the above-mentioned flow has the following drawbacks:

1) files under the/etc/init.d/directory are not all service initiation scripts, so directly reading the contents under the directory can cause the obtained service directory to be inaccurate.

2) It is lacking accuracy to judge whether a service has started running directly from the service status command service xxx status because: not all scripts are written strictly in a specific format, which is not conducive to automated management of various services.

3) The method cannot acquire the performance overhead of the service, and the performance overhead is important for managing the service and monitoring whether the service is abnormal or not.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

The embodiment of the invention provides a service list generation method, a service list generation device and a service list generation system, and an acquisition and reporting method and device, which are used for at least solving the technical problem that the automatic management of Linux service cannot be realized because the service list and a process list cannot be matched with each other in the related technology.

According to an aspect of an embodiment of the present invention, there is provided a service list generation system including:

the system comprises a first terminal and one or more servers, wherein the first terminal is used for sending a request message to the one or more servers, and the request message is used for acquiring a service list of one or more second terminals currently managed by the one or more servers; the server or the servers are used for determining the script file identification of the partial or all initialization types and the process identification corresponding to the script file identification of the partial or all initialization types of the second terminal by receiving the request message sent by the first terminal, generating a service list according to the determined script file identification and the process identification, and sending the service list to the first terminal; and the one or more second terminals are used for reporting the currently running script file identification and the currently running process identification to one or more servers.

According to another aspect of the embodiments of the present invention, there is provided a service list generation method, including:

receiving a request message from a first terminal, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by a server; determining script file identifications of partial or all initialization types of one or more second terminals; determining process identifications corresponding to part or all of the script file identifications of the initialization type; generating a service list according to the determined script file identifier and the process identifier; and sending the service list to the first terminal.

Optionally, the script file identification corresponds to a script file.

Optionally, the script file corresponds to launching the running associated service.

Optionally, determining the script file identifier of the partial or full initialization type includes: inquiring the currently existing script file identification and the script type corresponding to each script file identification; removing script file identifications of preset types from the currently existing script file identifications according to script types, and screening to obtain script file identifications of partial or all initialization types, wherein the script file identifications of preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

Optionally, before determining the process identifier corresponding to the script file identifier, the method further includes: inquiring the process identification currently existing; acquiring running state information of each process identifier in the currently existing process identifiers; and establishing an association relation between each process identification and the corresponding running state information.

Optionally, determining a process identifier corresponding to a script file identifier of a partial or full initialization type includes: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; and if one or more process identifiers in the currently existing process identifiers are determined to be the same as any one of the script file identifiers of the initialization type in the script file identifiers of part or all of the initialization types, establishing a corresponding relation between the determined process identifiers and the script file identifiers of the initialization types.

Optionally, determining a process identifier corresponding to a script file identifier of a partial or full initialization type includes: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; if it is determined that one or more process identifiers in the currently existing process identifiers are different from the file identifiers of the script files of any initialization type in the script file identifiers of part or all initialization types, calculating the similarity of the currently existing process identifiers and the script file identifiers of each initialization type in the script file identifiers of part or all initialization types; and establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

Optionally, the calculating the similarity between the currently existing process identifier and the script file identifier of each initialization type in the script file identifiers of part or all of the initialization types includes: acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and is less than or equal to T1, N is more than or equal to 1 and is less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers; and calculating a first difference value between M and K and a second difference value between N and K, and solving the sum of the first difference value and the second difference value to obtain a difference value between the Mth process identifier and the Nth initialization type script file identifier, wherein M is the length of the character string contained in the Mth process identifier, and N is the length of the character string contained in the Nth initialization type script file identifier.

Optionally, the establishing a correspondence between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type includes: comparing the difference value with a preset threshold value; and if the difference value is smaller than the preset threshold value, establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier.

Optionally, after generating the service list according to the determined script file identifier and the process identifier, at least one of the following is further included: determining the running state of the service corresponding to the script file identifier of the initialization type according to whether the corresponding process identifier exists in the script file identifier of each initialization type; respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type; after receiving one or more service commands, sequentially executing each service command in the one or more service commands, and after a preset time length, acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

According to another aspect of the embodiments of the present invention, there is provided a service list acquiring method, including:

sending a request message to a server, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by the server; and receiving and displaying a service list sent by the server, wherein the server list is generated according to the determined script file identification and the process identification after the server determines the script file identification of part or all of the initialization types and the process identification corresponding to the script file identification of part or all of the initialization types of the second terminal.

According to another aspect of the embodiments of the present invention, a method for reporting a service list is provided, including:

acquiring a currently running script file identifier and a currently running process identifier; and reporting the obtained script file identification and the process identification to a server.

According to still another aspect of the embodiments of the present invention, there is provided a service list generation apparatus, including:

the server comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving a request message from a first terminal, and the request message is used for acquiring a service list of one or more second terminals currently managed by the server; the first determining module is used for determining script file identifications of partial or all initialization types of one or more second terminals; the second determining module is used for determining a process identifier corresponding to a part or all of the script file identifiers of the initialization types; the generating module is used for generating a service list according to the determined script file identifier and the process identifier; and the sending module is used for sending the service list to the first terminal.

Optionally, the script file identification corresponds to a script file.

Optionally, the first determining module includes: the query unit is used for querying the currently existing script file identification and the script type corresponding to each script file identification; the clearing unit is used for clearing script file identifications of preset types from the currently existing script file identifications according to script types, and screening to obtain part or all of the script file identifications of the initialization types, wherein the script file identifications of the preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

Optionally, the apparatus further comprises: the query module is used for querying the process identification which currently exists; the acquisition module is used for acquiring the running state information of each process identifier in the currently existing process identifiers; and the establishing module is used for establishing an association relation between each process identification and the corresponding running state information.

Optionally, the second determining module includes: the first comparison unit is used for comparing the currently existing process identifier with the script file identifier of each initialization type in the script file identifiers of part or all initialization types; and the first establishing unit is used for establishing a corresponding relation between the determined process identifier and the script file identifier of the initialization type if one or more process identifiers in the currently existing process identifiers are determined to be the same as any one of the script file identifiers of the partial or all initialization types.

Optionally, the second determining module includes: the second comparison unit is used for comparing the currently existing process identifier with the script file identifier of each initialization type in the script file identifiers of part or all initialization types; the calculation unit is used for calculating the similarity between the currently existing process identifier and the script file identifier of each initialization type in the script file identifiers of part or all initialization types if it is determined that one or more process identifiers in the currently existing process identifiers are different from the file identifier of any initialization type script file in the script file identifiers of part or all initialization types; and the second establishing unit is used for establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

Optionally, the calculation unit comprises: the acquiring subunit is used for acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and less than or equal to T1, N is more than or equal to 1 and less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers; and the calculating subunit is configured to calculate a first difference between M and K and a second difference between N and K, and calculate a sum of the first difference and the second difference to obtain a difference value between the mth process identifier and the nth initialization type script file identifier, where M is a length of a character string included in the mth process identifier, and N is a length of a character string included in the nth initialization type script file identifier.

Optionally, the second establishing unit includes: the comparison subunit is used for comparing the difference value with a preset threshold value; and the establishing subunit is used for establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier if the difference value is smaller than a preset threshold value.

Optionally, the apparatus comprises at least one of: a third determining module, configured to determine, according to whether a corresponding process identifier exists in each initialization-type script file identifier, an operating state of a service corresponding to the initialization-type script file identifier; the calculation module is used for respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type; the execution module is used for executing each service command in the one or more service commands in sequence after receiving the one or more service commands, and acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list after the preset time length; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

According to still another aspect of the embodiments of the present invention, there is provided a service list acquiring apparatus, including:

the server comprises a sending module, a receiving module and a sending module, wherein the sending module is used for sending a request message to the server, and the request message is used for acquiring a service list of one or more second terminals currently managed by the server; the receiving module is used for receiving a service list sent by the server, wherein the server list is generated according to the determined script file identifier and the process identifier after the server determines the script file identifier of the partial or all initialization types and the process identifier corresponding to the script file identifier of the partial or all initialization types of the second terminal; and the display module is used for displaying the service list.

According to another aspect of the embodiments of the present invention, there is provided a service list reporting apparatus, including:

the acquisition module is used for acquiring the currently running script file identifier and the currently running process identifier; and the reporting module is used for reporting the obtained script file identifier and the process identifier to the server.

In the embodiment of the invention, after receiving the request message from the first terminal for acquiring the service list of one or more second terminals currently managed by one or more servers, determining the script file identification of part or all of the initialization type of one or more second terminals and determining the process identification corresponding to the script file identification of part or all of the initialization type, and generates a service list according to the determined script file identifier and the process identifier, thereby achieving the purpose of checking the service list corresponding to each second terminal under the second terminal cluster in real time, thereby realizing the technical effect of providing convenience and technical support for the automatic management of the Linux service by adopting the service script file and the integrated service list of the process contrast, and further, the technical problem that the automatic management of the Linux service cannot be realized due to the fact that mutual matching between the service list and the process list cannot be realized in the related technology is solved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

FIG. 1 is a schematic diagram of a scenario of a service list generation system according to an embodiment of the present invention;

fig. 2 is a list of a plurality of terminals managed by a server according to a preferred embodiment of the present invention;

fig. 3 is a service list corresponding to a specific terminal according to a preferred embodiment of the present invention;

FIG. 4 is a flow diagram of a service list generation method according to an embodiment of the present invention;

fig. 5 is a flowchart of a service list acquisition method according to an embodiment of the present invention;

fig. 6 is a flowchart of a service list reporting method according to an embodiment of the present invention;

fig. 7 is a block diagram of a structure of a service list generation apparatus according to an embodiment of the present invention;

fig. 8 is a block diagram of a structure of a service list generation apparatus according to a preferred embodiment of the present invention;

fig. 9 is a block diagram of a structure of a service list acquisition apparatus according to an embodiment of the present invention;

fig. 10 is a block diagram of a structure of a service list reporting apparatus according to an embodiment of the present invention;

fig. 11 is a block diagram of a server according to an embodiment of the present invention.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example 1

According to the embodiment of the invention, the embodiment of the system for updating the service list is also provided. Fig. 1 is a schematic view of a scenario of a service list generation system according to an embodiment of the present invention. As shown in fig. 1, the system may include: the system comprises a first terminal and one or more servers, wherein the first terminal is used for sending a request message to the one or more servers, and the request message is used for acquiring a service list of one or more second terminals currently managed by the one or more servers; the server or the servers are used for determining the script file identification of the partial or all initialization types and the process identification corresponding to the script file identification of the partial or all initialization types of the second terminal by receiving the request message sent by the first terminal, generating a service list according to the determined script file identification and the process identification, and sending the service list to the first terminal; and the one or more second terminals are used for reporting the currently running script file identification and the currently running process identification to one or more servers.

In particular, the one or more servers may be Database Management System (DMS) servers. The first terminal and the DMS server may establish communication via a hypertext transfer protocol (HTTP), i.e. the first terminal may send a request message to the DMS using the HTTP protocol and the first terminal may also receive a list of services from the DMS server using the HTTP protocol. In addition, a remote protocol based on a Linux kernel can be used for communication between the DMS server and one or more second terminals, for example: remote terminal protocol (Telnet), secure shell protocol (SSH). Further, the script file identification corresponds to a script file, and the script file corresponds to a service related to the self-starting operation of the Linux system.

As an optional embodiment of the present invention, the first terminal may send the request message to a plurality of servers, which is advantageous in that: in the case that only one server works, if the server goes down due to a failure, the first terminal cannot acquire the service list from the server. Therefore, under the condition that a plurality of servers are adopted, because the first terminal already sends the request message to the plurality of servers, even if one of the servers goes down due to failure, the failed server can be replaced by other servers in a main/standby switching manner, so that the first terminal can be ensured to successfully acquire the service list. In addition, under the condition of adopting a plurality of servers, if the load of one server is too high, the request message cannot be processed in time, and at the moment, the server with lower load can be selected to provide the service.

Fig. 2 is a plurality of terminal lists managed by a server according to a preferred embodiment of the present invention. As shown in fig. 2, after the first terminal logs in the server by using the cloud account, it is able to view all terminals managed by the server, an operating system respectively used by each terminal, a location of each terminal, and a corresponding current operating state (including but not limited to CPU usage, memory occupancy, and disk usage).

Fig. 3 is a service list corresponding to a specific terminal according to a preferred embodiment of the present invention. As shown in fig. 3, after one of the terminals currently managed by the server is selected, a service list corresponding to the terminal may be displayed on the first terminal, where the service list may include a script file identifier of a part or all of the initialization types under the selected terminal and a process identifier corresponding to the script file identifier of the part or all of the initialization types; in addition, the current running state corresponding to each service and whether the service belongs to the initialization type (i.e. startup) can also be included. Furthermore, the user can edit the script for each service according to specific requirements, and the service is closed or the self-starting is cancelled.

In the above operating environment, the present application provides a method of generating a service list as shown in fig. 4. Fig. 4 is a flowchart of a service list generation method according to an embodiment of the present invention. As shown in fig. 4, the method may include the following process steps:

step S402: receiving a request message from a first terminal, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by a server;

step S404: determining script file identifications of partial or all initialization types of one or more second terminals;

step S406: determining process identifications corresponding to part or all of the script file identifications of the initialization type;

step S408: generating a service list according to the determined script file identifier and the process identifier;

step S410: and sending the service list to the first terminal.

The script file identification list of all types not only contains the script file identification of the initialization type (i.e. start/stop) of various services of the system, but also may contain the executable script file identification or the link script file identification of a plurality of services. Therefore, the script file identifiers of other types (for example, the executable script file identifier or the link script file identifier) except the script file identifier of the initialization type included in the script file identifier list need to be filtered, so as to filter out the script file identifiers of part or all of the initialization types.

After the process identification list at the current moment is obtained, all process identifications in the running state at the current moment can be determined, wherein the process identifications are matched with the script file identifications of the initialization type in the script file identification list respectively, i.e. the script file identification for each initialization type may correspond to one or more process identifications in a process identification list, therefore, one or more process identifications matched with each of the one or more initialization type script file identifications are added into the service list through the matching operation, the technical effect of providing convenience and technical support for the automatic management of the Linux service by adopting the service script file and the integrated service list of the process contrast is realized, and further, the technical problem that the automatic management of the Linux service cannot be realized due to the fact that mutual matching between the service list and the process list cannot be realized in the related technology is solved.

Optionally, in step S404, determining the script file identifier of the partial or full initialization type may include the following steps:

step S4041: inquiring the currently existing script file identification and the script type corresponding to each script file identification;

the init.d directory contains the start and stop script file identifications of the various services of the system, which are responsible for controlling all the various transactions from acpid (acpid is a new power management standard of linux operating system) to X11-common (X11 is also called X Window system, and X Window system (X11 or X) is a Window system with bitmap display, which is a standard toolkit and protocol for establishing a graphical user interface on the basis of Unix and Unix-like operating systems and OpenVMS, and can be used for almost existing modern operating systems).

When a view/etc directory is needed, a number of directories in the form of rc #. d can be found (where # represents a specified initialization level, ranging from 0-6). Under these directories, many script file identifications that control the processes are included. These script file identifications start with either "K" or "S", wherein the script file identification starting with K runs before the script file identification starting with S, and the location where these scripts are placed will determine when these scripts start to run, and the specific command format is as follows:

the/etc/init.d/command option;

the command of the actual operation is the command, and the options can be as follows:

(1) start (start);

(2) stop (stop);

(3) reloading (reload);

(4) restart (restart);

(5) force-reload;

among the above options, the start, stop, and restart options are used more frequently. For example, if a network shutdown is required, a command of the form: d/network stop. As another example, if network settings have been modified and a network restart is required, the following command may be used: (etc./init. d/network restart)

The initialization script file identifier commonly used in the init.d directory may include, but is not limited to, at least one of the following:

(1)networking；

(2)samba；

(3)apache2；

(4)ftpd；

(5)sshd；

(6)dovecot；

(7)mysql。

the ls command is the most commonly used command in Linux. The ls command is an abbreviation of a list (list), and the ls command is used by default to present a list of service script files under the current default directory, and if ls is assigned to other directories, the service script files and the list of folders under the assigned directory are displayed. In addition, the ls command can not only view the files contained in the Linux folder, but also view the file authority (including directory, folder and file authority), view the directory information and the like.

L, which is an ls command option, represents detailed information listing the script file.

F, which is an ls command option, indicates that a character may be appended after each file name to illustrate the type of the file, where "+" indicates an executable general file, "/" indicates a directory, "@" indicates a symbolic link, "|" indicates FIFOs, and "═ indicates sockets.

The result of performing ls/etc corresponds to a file (the content is a list of file names under/etc), and the result of performing ls/etc/init.d/is used to list a list of services that can be started or stopped.

Step S4042: removing script file identifications of preset types from the currently existing script file identifications according to script types, and screening to obtain script file identifications of partial or all initialization types, wherein the script file identifications of preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

All types of service script file identifications contained in the service list can be obtained by using ls-1-F/etc/init.d/system command, and then script file identifications at the tail of a symbol "@" and a symbol "@" are filtered out, so that the script file identifications of partial or all initialization types are obtained through screening.

Optionally, before determining the process identifier corresponding to the script file identifier in step S406, the following steps may be further included:

step S411: querying the currently existing process identification by using a system command (such as ps-ef);

step S412: acquiring running state information of each process identifier in the currently existing process identifiers by adopting a system command (such as: proc/< pid >/stat);

step S413: and establishing an association relation between each process identification and the corresponding running state information.

The process status (ps) command in l inux is a process check command with high use frequency and powerful functions in the Linux system, and by running the command, the current running and running states of processes, whether the processes are finished, whether the processes are dead, and whether the processes occupy excessive resources can be determined. The most common applicable scenario for ps commands is for monitoring the behavior of background processes.

And checking all current process identifications by operating ps-ef, wherein various parameters corresponding to each process identification are explained as follows:

(1) USER represents the USER account to which the process belongs;

(2) PID indicates the number of the process;

(3) % CPU represents the percentage of CPU resources consumed by the process;

(4) % MEM represents the percentage of physical memory occupied by the process;

(5) VSZ represents the amount of virtual memory (Kbytes) consumed by the process;

(6) RSS represents the fixed amount of memory (Kbytes) occupied by the process;

(7) TTY indicates on which terminal the process is operating;

(8) STAT represents the current status of the process, which may include, but is not limited to, one of:

1) r indicates that the process is currently operating or can be operated;

2) s indicates that the process is currently asleep but may be awakened by a signal;

3) t indicates that the process is currently detecting or has stopped;

4) z indicates that the process should have terminated, but its parent cannot terminate it normally, resulting in a state of deadlock (zoobrie);

(9) START represents the time that the process is triggered to START;

(10) TIME represents the TIME that the process actually uses the CPU to operate;

(11) COMMAND indicates the instruction to which the process actually corresponds.

The/proc/< pid >/stat is a command for viewing the process state under the Linux system.

Under the Linux system, the state of a process may generally include the following:

(1) run state (running or waiting in a run queue);

(2) interrupt state (sleeping, blocked running, waiting for the formation of a specific condition or the receipt of a specific signal);

(3) an uninterruptible state (a process must wait until an interrupt occurs, receiving a particular signal does not wake up and is not operational);

(4) a dead state (process has terminated, but process descriptor still exists until released after parent process executes wait4() system call);

(5) stop state (the process stops running after receiving SIGTOP, SIGSTP, SIGTIN, SIGTOU signals).

The specific definitions of the parameters output by executing the/proc/< pid >/stat system command are as follows:

(1) name represents the Name of the application or command;

(2) state represents the State of a task, including but not limited to: operation, sleep, death;

(3) SleepAVG represents the average waiting time (in nanosequenced) of the task;

(4) tgid represents a thread group number;

(5) pid denotes a task Identification (ID);

(6) ppid represents a parent process ID;

(7) TracerPid indicates the ID number of the process receiving the trace information of the process;

(8) FDSize represents the maximum number of file descriptors;

(9) vmsize (kb) represents the size of the task virtual address space, where total _ vm is the size of the address space of the process, and reserved _ vm is the physical page of the process between reserved or special memories;

(10) vmlck (kb) represents the size of physical memory that a task has locked, which cannot be swapped to a hard disk;

(11) vmrss (kb) represents the size of physical memory being used by the application, i.e., the value of parameter rss with ps command;

(12) vmdata (kb) represents the size of the program data segment (i.e., the size of the virtual memory occupied) and stores initialized data;

(13) VmStk (KB) represents the size of the stack of tasks in user state;

(14) vmexe (kb) represents the size of executable virtual memory owned by a program, code fragments, libraries not used by tasks;

(15) VmLib (KB) represents the size of the library that is mapped to the virtual memory space of the task;

(16) VmPTE represents the size of all page tables for this process, in units: kb;

(17) threads represents the number of tasks that share the signal descriptor, and in a POSIX multithreading application, all Threads in a thread group use the same signal descriptor.

(18) SigQ represents the number of signals to be processed;

(19) SigPnd represents a mask bit, and stores a signal to be processed of the thread;

(20) ShdPnd represents a mask bit, and stores the signals to be processed of the thread group;

(21) SigBlk stores the blocked signal;

(22) SigIgn stores ignored signals;

(23) SigCgt stores the captured signal;

(24) CapInh Inheritable represents the inherited capabilities of a program that can be executed by the current process;

(25) CapPrm Permitted represents the ability of a process to be used and may include the ability not present in Capeff, which is temporarily abandoned by the process itself, Capeff being a subset of CapPrm, the ability of a process to abandon unnecessary contributing to increased security;

(26) capeff Effect represents the Effective capacity of a process.

In a preferred embodiment, the ps-ef system command can be used to first get the process identification list (second column pid), and then the reuse/proc/file system gets the information of the process, which can include but is not limited to: the detailed information of the process comprises a process number, a process name, a user, a CPU and the utilization rate of a memory in/proc/< pid >/stat, and then the acquired information is added into a process list.

Optionally, in step S406, determining a process identifier corresponding to a script file identifier of a partial or full initialization type may include the following steps:

step S4061: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types;

step S4062: and if one or more process identifiers in the currently existing process identifiers are determined to be the same as any one of the script file identifiers of the initialization type in the script file identifiers of part or all of the initialization types, establishing a corresponding relation between the determined process identifiers and the script file identifiers of the initialization types.

The service script file identifier of the initialization type in the script file identifier list may be independent of the process identifier in the process identifier list, or may be related to the process identifier in the process identifier list. Furthermore, the service script file identifier of an initialization type in the script file identifier list may be related to only one process identifier in the process identifier list, or may be related to a plurality of process identifiers in the process list. The purpose of performing the matching operation between the script file identifier list and the process identifier list is to add the determined one or more process identifiers to the service list and establish a corresponding relationship between the determined one or more process identifiers and the service script file identifier of the initialization type in the service list if it can be determined that the service script file identifier of any initialization type in the script file identifier list has the corresponding one or more process identifiers in the process identifier list.

Specifically, whether the file name and the process name of the script file of the initialization type with the identical name exist can be searched from the script file identification list and the process identification list respectively, and if the file name and the process name of the script file of the initialization type with the identical name exist, the process with the identical name is directly added into the service list. For example: assuming that a script file identifier with an initialization type name of auto fs (automatic installation service) exists in the script file identifier list and a process identifier with a name of auto fs (automatic installation management process) exists in the process identifier list, the process identifier auto fs needs to be added to the service list, and a corresponding relationship is established between the auto fs service and the auto fs process. For another example: assuming that a script file identifier of an initialization type called bootparam exists in the script file identifier list and a process identifier named bootparam exists in the process identifier list, the bootparam process identifier needs to be added into the service list, and a corresponding relationship is established between the script file identifier bootparam and the process identifier bootparam.

step S4063: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types;

step S4064: if it is determined that one or more process identifiers in the currently existing process identifiers are different from the file identifiers of the script files of any initialization type in the script file identifiers of part or all initialization types, calculating the similarity of the currently existing process identifiers and the script file identifiers of each initialization type in the script file identifiers of part or all initialization types;

step S4065: and establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

In the actual comparison process, except for determining that the process name of one or more processes in all the processes is the same as the file name of any one of the script files of the initialization type, or in the case that the process name of one or more processes in all the processes is not found to be the same as the file name of any one of the script files of the initialization type, the corresponding relationship between the script file of the initialization type and one or more processes needs to be established by calculating the similarity between the process name and the file name.

Specifically, the similarity between the file name and the process name can be calculated by the longest common substring algorithm. For example: the file name is "acetfe", the process name is "aede", and the longest common substring of the file name and the process name is the character string "aede", that is, no matter whether the characters in the character string are adjacent or not, the character string is the substring which is contained in both the file name and the process name and has the longest length.

Optionally, in step S4064, calculating a similarity package between the currently existing process identifier and each of the script file identifiers of some or all of the initialization types may include the following steps:

step S40641: acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and is less than or equal to T1, N is more than or equal to 1 and is less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers;

step S40642: and calculating a first difference value between M and K and a second difference value between N and K, and solving the sum of the first difference value and the second difference value to obtain a difference value between the Mth process identifier and the Nth initialization type script file identifier, wherein M is the length of the character string contained in the Mth process identifier, and N is the length of the character string contained in the Nth initialization type script file identifier.

In a preferred embodiment, the matching method is a difference matching algorithm, and the specific operation process is as follows:

supposing that the name of the Mth process is M [ M ] and the name of the file of the script file of the Nth initialization type is N [ N ], wherein M is the length of a character string contained in the process name of the Mth process, and N is the length of a character string contained in the file name of the script file of the Nth initialization type; the matching threshold is set to t (normally set to 2) in advance. The specific alignment process may comprise the steps of:

the first step, comparing whether the Mth process name M [ M ] is completely the same as the file name N [ N ] of the Nth initialization type script file, if not, continuing to execute the second step;

secondly, running a maximum common substring algorithm to obtain a maximum common substring P [ k ] between the Mth process name M [ M ] and the file name N [ N ] of the Nth initialization type script file;

thirdly, calculating the difference value (diff) between the Mth process name M [ M ] and the file name N [ N ] of the Nth initialization type script file as follows: diff is m-k + p-k.

Optionally, in step S4065, the establishing a correspondence between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type may include the following steps:

step S40651: comparing the difference value with a preset threshold value;

step S40652: and if the difference value is smaller than the preset threshold value, establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier.

After calculating the difference value, comparing the difference value (diff) with a preset matching threshold t (for example, t is 2), and adding the mth process to the service list if diff < t; if diff is larger than or equal to t, the similarity between the M +1 process name M [ M ] and the file name of the script file of the Nth initialization type is continuously calculated.

Optionally, in step S408, after generating the service list according to the determined script file identifier and the process identifier, at least one of the following steps may be further included:

step S414: and determining the running state of the service corresponding to the script file identifier of the initialization type according to whether the corresponding process identifier exists in the script file identifier of each initialization type.

If one or more process identifiers corresponding to the script file identifier of the initialization type in the service list exist (that is, the number of the process identifiers matching with the script file identifier of the initialization type is greater than or equal to 1), the service corresponding to the script file identifier of the initialization type can be considered to be in a normal running state. However, if one or more process identifiers corresponding to the script file identifier of the initialization type do not exist in the script file identifier of the initialization type in the service list (that is, the number of the process identifiers matching with the script file identifier of the initialization type is 0), it can be considered that the service corresponding to the script file identifier of the initialization type is in an un-running state, so that a service state judgment method independent of the script and the service command is realized, and the accuracy of the judgment is improved.

Step S415: and respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type.

Because one or more process identifications matched with one initialization type script file identification are added into the service list, the performance cost of the initialization type script file identification can be calculated through a performance index set (including but not limited to CPU occupation rate, memory occupation rate and network flow) corresponding to the one or more process identifications, and therefore the performance cost of the service can be acquired more accurately.

Specifically, assuming that the process identifier B, the process identifier C, and the process identifier D corresponding to the script file identifier a of the initialization type are added to the service list and establish a corresponding relationship with the script file identifier a of the initialization type, and further assuming that the CPU occupancy of the process identifier B is 5%, the CPU occupancy of the process identifier C is 15%, and the CPU occupancy of the process identifier D is 5%, then the script file identifier a of the initialization type is the sum (i.e., 25%) of the CPU occupancy of the process identifier B, the CPU occupancy of the process identifier C, and the CPU occupancy of the process identifier D on the performance index of the CPU occupancy.

Step S416: after receiving one or more service commands, sequentially executing each service command in the one or more service commands, and after a preset time length, acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

The preset storage area may be a message (or behavior) queue, and considering that the processes of obtaining the service command and processing the service command are likely to be asynchronous, it is necessary to store one or more service commands sent by the user through the message (or behavior) queue and then execute the service commands one by one, for a successfully executed service command, the successfully executed service command may be deleted from the queue, and for an unsuccessfully executed service command, it is necessary to detect whether the successfully executed service command can be executed.

When a user initiates to start or close a specific service from the front end of the client, the user behavior can be recorded in a user behavior queue, then a delay mechanism is set, the service state is obtained at regular time, if the service state is not changed after a certain time, the user is prompted to fail to start or close the service, otherwise, a success message is prompted.

For example: firstly, storing an opening command of the acpi service, an opening command of the adsl service, an opening command of the arpwatch service, an opening command of the cups service and an opening command of the dhcpd service into a user behavior queue, then, executing the opening command of the acpi service, the opening command of the adsl service, the opening command of the arpwatch service, the opening command of the cups service and the opening command of the dhcpd service one by one, storing the opening command of the acpi service, the opening command of the adsl service, the opening command of the arpwatch service, the opening command of the cups service and the opening command of the dhcpd service into the user behavior queue, simultaneously, setting a delay mechanism, obtaining service states executed according to the opening commands at regular time, if it is found that the service states are not changed after a certain time, prompting that the user service is opened unsuccessfully, and otherwise, prompting the user that all services are opened successfully.

In the above operating environment, the present application provides a service list acquisition method as shown in fig. 5. The method is applied to the first terminal. Fig. 5 is a flowchart of a service list acquisition method according to an embodiment of the present invention. As shown in fig. 5, the method may include the following process steps:

step S502: sending a request message to a server, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by the server;

step S504: and receiving and displaying a service list sent by the server, wherein the server list is generated according to the determined script file identification and the process identification after the server determines the script file identification of part or all of the initialization types and the process identification corresponding to the script file identification of part or all of the initialization types under the second terminal.

Under the above operating environment, the present application provides a service list reporting method as shown in fig. 6. The method is applied to the one or more second terminals. Fig. 6 is a flowchart of a service list reporting method according to an embodiment of the present invention. As shown in fig. 6, the method may include the following process steps:

step S602: acquiring a currently running script file identifier and a currently running process identifier;

step S604: and reporting the obtained script file identification and the process identification to a server.

The communication between the first terminal and the DMS server (cluster) may be established via HTTP, i.e. the first terminal may send a request message to the DMS using the HTTP protocol and the first terminal may also receive a list of services from the DMS server (cluster) using the HTTP protocol. The service list of the second terminal (cluster) currently managed by the DMS server (cluster) is learned by sending a request message to the DMS server (cluster). In order to generate the server list, a remote protocol based on a Linux kernel may be used to communicate between the DMS server (cluster) and the second terminal (cluster), for example: telnet, SSH. Each second terminal can actively acquire the currently running script file identifier and the currently running process identifier on the terminal according to a preset period, and can also acquire the currently running script file identifier and the currently running process identifier on the terminal according to the query instruction after receiving the query instruction from the DMS server (cluster); similarly, each second terminal may report the obtained script file identifier and process identifier actively according to a preset period, or may report the obtained script file identifier and process identifier according to an inquiry instruction after receiving an inquiry instruction from the DMS server (cluster).

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the order of acts, as some steps may occur in other orders or concurrently in accordance with the invention. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required by the invention.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method for updating the service list according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

Example 2

According to an embodiment of the present invention, an embodiment of an apparatus for implementing the service list generating method is further provided, and fig. 7 is a block diagram of a structure of the service list generating apparatus according to the embodiment of the present invention. As shown in fig. 7, the apparatus includes: a receiving module 700, configured to receive a request message from a first terminal, where the request message is used to obtain a service list of one or more second terminals currently managed by a server; a first determining module 702, configured to determine script file identifiers of partial or all initialization types of one or more second terminals; a second determining module 704, configured to determine a process identifier corresponding to a script file identifier of a partial or full initialization type; a generating module 706, configured to generate a service list according to the determined script file identifier and the process identifier; a sending module 708, configured to send the service list to the first terminal.

Optionally, the script file identification corresponds to a script file.

Optionally, the first determining module 702 may include: a query unit (not shown in the figure) configured to query currently existing script file identifiers and script types corresponding to each script file identifier; a clearing unit (not shown in the figure), configured to clear a script file identifier of a predetermined type from currently existing script file identifiers according to a script type, and filter to obtain a script file identifier of a partial or all initialization types, where the script file identifier of the predetermined type includes: all executable type script file identifications and/or all symbolic link type script file identifications.

Alternatively, fig. 8 is a block diagram of a structure of a service list generation apparatus according to a preferred embodiment of the present invention. As shown in fig. 8, the apparatus may further include: a query module 710, configured to query a currently existing process identifier; an obtaining module 712, configured to obtain running state information of each process identifier in the currently existing process identifiers; an establishing module 714, configured to establish an association relationship between each process identifier and corresponding running state information.

Optionally, the second determining module 704 may include: a first comparing unit (not shown in the figure), configured to compare the currently existing process identifier with a script file identifier of each initialization type in script file identifiers of part or all initialization types; a first establishing unit (not shown in the figure), configured to, if it is determined that one or more process identifiers in currently existing process identifiers are the same as any one of the script file identifiers of the initialization type in some or all of the script file identifiers of the initialization type, establish a corresponding relationship between the determined process identifiers and the script file identifiers of the initialization type.

Optionally, the second determining module 704 may include: a second comparing unit (not shown in the figure), configured to compare the currently existing process identifier with a script file identifier of each initialization type in script file identifiers of some or all initialization types; a calculating unit (not shown in the figure), configured to calculate a similarity between a currently existing process identifier and a script file identifier of each initialization type in the script file identifiers of part or all initialization types, if it is determined that one or more process identifiers in the currently existing process identifiers are different from a file identifier of any one initialization type script file in the script file identifiers of part or all initialization types; and a second establishing unit (not shown in the figure) for establishing a corresponding relationship between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

Alternatively, the calculation unit may include: an obtaining subunit (not shown in the figure), configured to obtain the number K of the same characters in the mth process identifier as in the nth script identifier of the initialization type, where M is greater than or equal to 1 and less than or equal to T1, N is greater than or equal to 1 and less than or equal to T2, T1 is the total number of process identifiers, T2 is the total number of script identifiers of the initialization type, and M, N, T1, and T2 are all positive integers; and a calculating subunit (not shown in the figure), configured to calculate a first difference between M and K and a second difference between N and K, and calculate a sum of the first difference and the second difference to obtain a difference between an mth process identifier and an nth initialization type script file identifier, where M is a length of a character string included in the mth process identifier, and N is a length of a character string included in the nth initialization type script file identifier.

Optionally, the second establishing unit may include: a comparison subunit (not shown in the figure) for comparing the difference value with a preset threshold value; and the establishing subunit is used for establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier if the difference value is smaller than a preset threshold value.

Optionally, as shown in fig. 8, the apparatus may further include at least one of: a third determining module 716, configured to determine, according to whether a corresponding process identifier exists in each script identifier of an initialization type, an operating state of a service corresponding to the script identifier of the initialization type; a calculating module 718, configured to calculate, through the performance index set of the process identifier corresponding to each initialization type script file identifier, a performance overhead of the service corresponding to each initialization type script file identifier; the execution module 720 is configured to, after receiving the one or more service commands, sequentially execute each service command in the one or more service commands, and after a preset duration, obtain, from the service list, an operation state of the script file of the initialization type corresponding to the currently executed service command; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

According to an embodiment of the present invention, an embodiment of an apparatus for implementing the service list acquiring method is further provided, and fig. 9 is a block diagram of a structure of the service list acquiring apparatus according to the embodiment of the present invention. As shown in fig. 9, the apparatus includes: a sending module 900, configured to send a request message to a server, where the request message is used to obtain a service list of one or more second terminals currently managed by the server; a receiving module 902, configured to receive a service list sent by a server, where the server list is generated according to a script file identifier and a process identifier determined by the server after the server determines a script file identifier of a part or all of initialization types and a process identifier corresponding to the script file identifier of the part or all of initialization types of the second terminal; a display module 904 for displaying the service list.

According to an embodiment of the present invention, an embodiment of an apparatus for implementing the service list reporting method is further provided, and fig. 10 is a block diagram of a structure of the service list reporting apparatus according to the embodiment of the present invention. As shown in fig. 10, the apparatus includes: an obtaining module 1002, configured to obtain a currently running script file identifier and a currently running process identifier; a reporting module 1004, configured to report the obtained script file identifier and the process identifier to the server.

Example 3

The embodiment of the invention can provide a computer terminal which can be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced with a terminal device such as a mobile terminal.

Optionally, in this embodiment, the computer terminal may be located in at least one network device of a plurality of network devices of a computer network.

Alternatively, fig. 11 is a block diagram of a server according to an embodiment of the present invention. As shown in fig. 11, the server may include: one or more processors (only one shown) and memory.

The memory may be configured to store software programs and modules, such as program instructions/modules corresponding to the service list generation method and apparatus in the embodiments of the present invention, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, so as to implement the service list generation method. The memory may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory remotely located from the processor, and these remote memories may be connected to the server over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The processor can call the information and application program stored in the memory through the transmission device to execute the following steps:

s1: receiving a request message from a first terminal, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by a server;

s2: determining script file identifications of partial or all initialization types of one or more second terminals;

s3: determining process identifications corresponding to part or all of the script file identifications of the initialization type;

s4: generating a service list according to the determined script file identifier and the process identifier;

s5: and sending the service list to the first terminal.

Optionally, the processor may further execute the program code of the following steps: inquiring the currently existing script file identification and the script type corresponding to each script file identification; removing script file identifications of preset types from the currently existing script file identifications according to script types, and screening to obtain script file identifications of partial or all initialization types, wherein the script file identifications of preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

Optionally, the processor may further execute the program code of the following steps: inquiring the process identification currently existing; acquiring running state information of each process identifier in the currently existing process identifiers; and establishing an association relation between each process identification and the corresponding running state information.

Optionally, the processor may further execute the program code of the following steps: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; and if one or more process identifiers in the currently existing process identifiers are determined to be the same as any one of the script file identifiers of the initialization type in the script file identifiers of part or all of the initialization types, establishing a corresponding relation between the determined process identifiers and the script file identifiers of the initialization types.

Optionally, the processor may further execute the program code of the following steps: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; if it is determined that one or more process identifiers in the currently existing process identifiers are different from the file identifiers of the script files of any initialization type in the script file identifiers of part or all initialization types, calculating the similarity of the currently existing process identifiers and the script file identifiers of each initialization type in the script file identifiers of part or all initialization types; and establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

Optionally, the processor may further execute the program code of the following steps: acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and is less than or equal to T1, N is more than or equal to 1 and is less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers; and calculating a first difference value between M and K and a second difference value between N and K, and solving the sum of the first difference value and the second difference value to obtain a difference value between the Mth process identifier and the Nth initialization type script file identifier, wherein M is the length of the character string contained in the Mth process identifier, and N is the length of the character string contained in the Nth initialization type script file identifier.

Optionally, the processor may further execute the program code of the following steps: comparing the difference value with a preset threshold value; and if the difference value is smaller than the preset threshold value, establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier.

Optionally, the processor may further execute the program code of the following steps: determining the running state of the service corresponding to the script file identifier of the initialization type according to whether the corresponding process identifier exists in the script file identifier of each initialization type; respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type; after receiving one or more service commands, sequentially executing each service command in the one or more service commands, and after a preset time length, acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

It will be understood by those skilled in the art that the structure shown in fig. 11 is only an illustration and is not intended to limit the structure of the electronic device. For example, the server may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 11, or have a different configuration than shown in FIG. 11.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing a terminal device or server-related hardware, and the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

Example 4

The embodiment of the invention also provides a storage medium. Optionally, in this embodiment, the storage medium may be configured to store a program code executed by the service list generating method provided in the first embodiment.

Optionally, in this embodiment, the storage medium may be located in any one of computer terminals in a computer terminal group in a computer network, or in any one of mobile terminals in a mobile terminal group.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:

s5: and sending the service list to the first terminal.

Optionally, the storage medium is further configured to store program codes for performing the following steps: inquiring the currently existing script file identification and the script type corresponding to each script file identification; removing script file identifications of preset types from the currently existing script file identifications according to script types, and screening to obtain script file identifications of partial or all initialization types, wherein the script file identifications of preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

Optionally, the storage medium is further configured to store program codes for performing the following steps: inquiring the process identification currently existing; acquiring running state information of each process identifier in the currently existing process identifiers; and establishing an association relation between each process identification and the corresponding running state information.

Optionally, the storage medium is further configured to store program codes for performing the following steps: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; and if one or more process identifiers in the currently existing process identifiers are determined to be the same as any one of the script file identifiers of the initialization type in the script file identifiers of part or all of the initialization types, establishing a corresponding relation between the determined process identifiers and the script file identifiers of the initialization types.

Optionally, the storage medium is further configured to store program codes for performing the following steps: comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types; if it is determined that one or more process identifiers in the currently existing process identifiers are different from the file identifiers of the script files of any initialization type in the script file identifiers of part or all initialization types, calculating the similarity of the currently existing process identifiers and the script file identifiers of each initialization type in the script file identifiers of part or all initialization types; and establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

Optionally, the storage medium is further configured to store program codes for performing the following steps: acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and is less than or equal to T1, N is more than or equal to 1 and is less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers; and calculating a first difference value between M and K and a second difference value between N and K, and solving the sum of the first difference value and the second difference value to obtain a difference value between the Mth process identifier and the Nth initialization type script file identifier, wherein M is the length of the character string contained in the Mth process identifier, and N is the length of the character string contained in the Nth initialization type script file identifier.

Optionally, the storage medium is further configured to store program codes for performing the following steps: comparing the difference value with a preset threshold value; and if the difference value is smaller than the preset threshold value, establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier.

Optionally, the storage medium is further configured to store program codes for performing the following steps: determining the running state of the service corresponding to the script file identifier of the initialization type according to whether the corresponding process identifier exists in the script file identifier of each initialization type; respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type; after receiving one or more service commands, sequentially executing each service command in the one or more service commands, and after a preset time length, acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

In the above embodiments of the present invention, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. A service list generation system, comprising:

the system comprises a first terminal and one or more second terminals, wherein the first terminal is used for sending a request message to one or more servers, and the request message is used for acquiring a service list of one or more second terminals currently managed by the one or more servers;

the one or more servers are configured to determine, by receiving the request message sent by the first terminal, a script file identifier of a part or all of the initialization types of the second terminal and a process identifier corresponding to the script file identifier of the part or all of the initialization types, generate the service list according to the determined script file identifier and the process identifier, and send the service list to the first terminal;

and the one or more second terminals are used for reporting the currently running script file identifier and the currently running process identifier to the one or more servers.

2. A method for generating a service list, comprising:

receiving a request message from a first terminal, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by a server;

determining script file identifications of partial or all initialization types of one or more second terminals;

determining a process identifier corresponding to the script file identifier of the partial or all initialization types;

generating the service list according to the determined script file identification and the process identification;

and sending the service list to the first terminal.

3. The method of claim 2, wherein the script file identification corresponds to a script file.

4. The method of claim 3, wherein the script file corresponds to launching the associated service.

5. The method of claim 2, wherein determining the script file identification of the partial or full initialization type comprises:

inquiring the currently existing script file identification and the script type corresponding to each script file identification;

removing script file identifications of preset types from the currently existing script file identifications according to the script types, and screening to obtain the script file identifications of part or all of the initialization types, wherein the script file identifications of the preset types comprise: all executable type script file identifications and/or all symbolic link type script file identifications.

6. The method according to claim 2, before determining the process identifier corresponding to the script file identifier, further comprising:

inquiring the process identification currently existing;

acquiring running state information of each process identifier in the currently existing process identifiers;

and establishing an association relation between each process identification and the corresponding running state information.

7. The method of claim 6, wherein determining the process identifier corresponding to the script file identifier of the partial or full initialization type comprises:

comparing the currently existing process identification with the script file identification of each initialization type in the script file identifications of part or all initialization types;

and if one or more process identifications in the currently existing process identifications are determined to be the same as any one of the script file identifications of the partial or all initialization types, establishing a corresponding relation between the determined process identifications and the script file identifications of the initialization types.

8. The method according to claim 6 or 7, wherein determining the process identifier corresponding to the script file identifier of the partial or full initialization type comprises:

if it is determined that one or more process identifications in the currently existing process identifications are different from the file identification of any one of the script file identifications of the partial or all initialization types, calculating the similarity between the currently existing process identifications and the script file identification of each initialization type in the script file identifications of the partial or all initialization types;

and establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

9. The method of claim 8, wherein calculating the similarity between the currently existing process id and each of the script file ids of the partial or full initialization types comprises:

acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and is less than or equal to T1, N is more than or equal to 1 and is less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers;

calculating a first difference value between M and K and a second difference value between N and K, and solving a sum of the first difference value and the second difference value to obtain a difference value between the Mth process identifier and the Nth initialization type script file identifier, wherein M is the length of a character string contained in the Mth process identifier, and N is the length of a character string contained in the Nth initialization type script file identifier.

10. The method according to claim 9, wherein establishing the correspondence between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type comprises:

comparing the difference value with the preset threshold value;

and if the difference value is smaller than a preset threshold value, establishing a corresponding relation between the Mth process identifier and the Nth initialization type script file identifier.

11. The method of claim 2, wherein after generating the service list according to the determined script file identifier and process identifier, further comprising at least one of:

determining the running state of the service corresponding to the script file identifier of the initialization type according to whether the corresponding process identifier exists in the script file identifier of each initialization type;

respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type;

after receiving one or more service commands, sequentially executing each service command in the one or more service commands, and after a preset time length, acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

12. A service list acquisition method, comprising:

sending a request message to a server, wherein the request message is used for acquiring a service list of one or more second terminals currently managed by the server;

and receiving and displaying the service list sent by the server, wherein the service list is generated according to the determined script file identifier and the process identifier after the server determines the script file identifier of the part or all of the initialization types of the second terminal and the process identifier corresponding to the script file identifier of the part or all of the initialization types.

13. A service list reporting method is characterized by comprising the following steps:

acquiring a currently running script file identifier and a currently running process identifier;

and reporting the obtained script file identification and the process identification to a server so that the server determines the script file identification of the initialization type and the process identification corresponding to the script file identification of the initialization type, and generating a service list according to the determined script file identification and the process identification.

14. A service list generation apparatus, comprising:

the server comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving a request message from a first terminal, and the request message is used for acquiring a service list of one or more second terminals currently managed by the server;

the first determining module is used for determining script file identifications of partial or all initialization types of one or more second terminals;

the second determining module is used for determining the process identifier corresponding to the script file identifier of the partial or all initialization types;

the generating module is used for generating the service list according to the determined script file identifier and the process identifier;

and the sending module is used for sending the service list to the first terminal.

15. The apparatus of claim 14, wherein the script file identification corresponds to a script file.

16. The apparatus of claim 15, wherein the script file corresponds to launching a service that runs an association.

17. The apparatus of claim 15, wherein the first determining module comprises:

the query unit is used for querying the currently existing script file identification and the script type corresponding to each script file identification;

a clearing unit, configured to clear a script file identifier of a predetermined type from the currently existing script file identifiers according to the script type, and filter to obtain a script file identifier of the partial or all initialization types, where the script file identifier of the predetermined type includes: all executable type script file identifications and/or all symbolic link type script file identifications.

18. The apparatus of claim 15, further comprising:

the query module is used for querying the process identification which currently exists;

the acquisition module is used for acquiring the running state information of each process identifier in the currently existing process identifiers;

and the establishing module is used for establishing an association relation between each process identification and the corresponding running state information.

19. The apparatus of claim 18, wherein the second determining module comprises:

a first comparing unit, configured to compare the currently existing process identifier with a script file identifier of each initialization type in the script file identifiers of the partial or all initialization types;

and the first establishing unit is used for establishing a corresponding relation between the determined process identifier and the script file identifier of the initialization type if one or more process identifiers in the currently existing process identifiers are determined to be the same as the script file identifier of any one of the partial or all of the script file identifiers of the initialization type.

20. The apparatus of claim 18, wherein the second determining module comprises:

a second comparing unit, configured to compare the currently existing process identifier with a script file identifier of each initialization type in the script file identifiers of the partial or all initialization types;

a calculating unit, configured to calculate a similarity between one or more process identifiers of the currently existing process identifiers and a script file identifier of any one of the partial or all initialization types of script file identifiers if it is determined that the process identifiers are different from the file identifiers of the script files of any one of the partial or all initialization types of script file identifiers;

and the second establishing unit is used for establishing a corresponding relation between the process identifier with the similarity smaller than the preset threshold and the script file identifier of the initialization type.

21. The apparatus of claim 20, wherein the computing unit comprises:

the acquiring subunit is used for acquiring the number K of the same characters in the Mth process identifier and the Nth script identifier of the initialization type, wherein M is more than or equal to 1 and less than or equal to T1, N is more than or equal to 1 and less than or equal to T2, T1 is the total number of the process identifiers, T2 is the total number of the script identifiers of the initialization type, and M, N, T1 and T2 are positive integers;

and the calculating subunit is configured to calculate a first difference between M and K and a second difference between N and K, and calculate a sum of the first difference and the second difference to obtain a difference between the mth process identifier and the nth initialization type script file identifier, where M is a length of a character string included in the mth process identifier, and N is a length of a character string included in the nth initialization type script file identifier.

22. The apparatus of claim 21, wherein the second establishing unit comprises:

a comparison subunit, configured to compare the difference value with the preset threshold;

and the establishing subunit is configured to establish a corresponding relationship between the mth process identifier and the nth script file identifier of the initialization type if the difference value is smaller than a preset threshold value.

23. The apparatus of claim 14, wherein the apparatus comprises at least one of:

a third determining module, configured to determine, according to whether a corresponding process identifier exists in each initialization-type script file identifier, an operating state of a service corresponding to the initialization-type script file identifier;

the calculation module is used for respectively calculating the performance overhead of the service corresponding to the script file identifier of each initialization type through the performance index set of the process identifier corresponding to the script file identifier of each initialization type;

the execution module is used for executing each service command in the one or more service commands in sequence after receiving the one or more service commands, and acquiring the running state of the script file of the initialization type corresponding to the currently executed service command from the service list after a preset time length; if the running state is changed, sending out prompt information that the execution of the service command is successful, and if the running state is not changed, sending out prompt information that the execution of the service command is failed.

24. A service list acquisition apparatus, comprising:

the terminal comprises a sending module, a receiving module and a sending module, wherein the sending module is used for sending a request message to a server, and the request message is used for acquiring a service list of one or more second terminals currently managed by the server;

the receiving module is configured to receive the service list sent by the server, where the server list is generated according to the determined script file identifier and the process identifier after the server determines the script file identifier of the part or all of the initialization types of the second terminal and the process identifier corresponding to the script file identifier of the part or all of the initialization types;

and the display module is used for displaying the service list.

25. A service list reporting apparatus, comprising:

the acquisition module is used for acquiring the currently running script file identifier and the currently running process identifier;

and the reporting module is used for reporting the obtained script file identification and the process identification to a server so that the server determines the script file identification of the initialization type and the process identification corresponding to the script file identification of the initialization type, and generates a service list according to the determined script file identification and the process identification.