CN110389878B - Program monitoring method, device, system on chip and storage medium - Google Patents
Program monitoring method, device, system on chip and storage medium Download PDFInfo
- Publication number
- CN110389878B CN110389878B CN201910610708.1A CN201910610708A CN110389878B CN 110389878 B CN110389878 B CN 110389878B CN 201910610708 A CN201910610708 A CN 201910610708A CN 110389878 B CN110389878 B CN 110389878B
- Authority
- CN
- China
- Prior art keywords
- program
- monitored
- monitoring
- pid file
- started
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a program monitoring method, a program monitoring device, a system-on-chip and a storage medium. The method is applied to a system on a chip on a vehicle, and the system on a chip runs a Linux system. Firstly, receiving a starting instruction sent by a system starter system of a Linux system; and when the starting is successful according to the starting instruction, monitoring the process identifier pid file output by the program to be monitored. The program to be monitored cannot be started and managed by the system. When the program to be monitored is abnormal (such as deadlock, crash, etc.), the output pid file will disappear. Because the pid file carries the unique identifier of the program to be monitored, when the pid file carrying a certain unique identifier is monitored to disappear, the program to be monitored corresponding to the unique identifier can be determined to be abnormal. The method can acquire the abnormal condition of the program started by the nonsystemed in time without changing the existing program starting logic, and improves the running safety of each program in the system.
Description
Technical Field
The present application relates to the field of program monitoring technologies, and in particular, to a program monitoring method, a program monitoring device, a system on a chip, and a storage medium.
Background
With the gradual enrichment of vehicle functions, many services provided by vehicles can be realized by virtue of a Linux system, such as a navigation service, a video playing service and the like. System md is a system starter in the Linux system, and is usually the first program initiated by the Linux kernel to provide program starting service for the Linux system. In addition, the system can also be used as a system manager to provide program management service for the Linux system.
However, in general, the system d can only manage the self-started programs, and some non-system-started programs, such as an image capturing application program, a radio application program and the like, exist in the Linux system, and these programs are not managed by the system md due to the requirement of quick start, and are non-system-started programs.
The problem is that when an exception occurs in a program that is not system d-initiated, such as a deadlock, crash or exit, it is not known by the system that the program that is not system d-initiated is abnormal because the system is not able to manage it.
Disclosure of Invention
Based on the above problems, the present application provides a program monitoring method, device, system on chip and storage medium, and the abnormal condition of the program started by the nonsystemd is known in time.
The embodiment of the application discloses the following technical scheme:
in a first aspect, the present application provides a program monitoring method applied to a system on chip SOC set on a vehicle, where the SOC runs a Linux system, the method including:
receiving a starting instruction sent by a system starter system of the Linux system;
when the starting instruction is started successfully, monitoring a process identifier pid file output by a program to be monitored; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored;
and when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal.
Optionally, after the determining that the program to be monitored is abnormal, the method further includes:
restarting the program to be monitored.
Optionally, the method further comprises:
and when the pid file is detected to be created, determining that the program to be monitored is successfully started.
Optionally, before the monitoring the process identifier pid file output by the program to be monitored, the method further comprises:
reading the name of a program to be monitored carried by an environment variable in a system d catalog;
and determining a corresponding program to be monitored according to the name.
Optionally, the monitoring the process identifier pid file output by the program to be monitored specifically includes:
and monitoring a process identifier pid file output by a program to be monitored through an inotify mechanism of the Linux system.
In a second aspect, the present application provides a program monitoring device applied to a system on chip SOC set on a vehicle, the SOC running a Linux system, the device comprising:
the starting instruction receiving module is used for receiving a starting instruction sent by a system starter system of the Linux system;
the file monitoring module is used for monitoring a process identifier pid file output by a program to be monitored when the starting is successful according to the starting instruction; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored;
and the program monitoring module is used for determining that the program to be monitored is abnormal when the pid file is monitored to disappear according to the unique identifier.
Optionally, the apparatus further comprises:
and the program restarting module is used for restarting the program to be monitored.
Optionally, the program monitoring module is further configured to determine that the program to be monitored is successfully started when it is monitored that the pid file is created.
Optionally, the apparatus further comprises:
the program name reading module is used for reading the name of the program to be monitored carried by the environment variable in the system md directory;
and the program determining module is used for determining a corresponding program to be monitored according to the name.
Optionally, the file monitoring module specifically includes:
and the first monitoring unit is used for monitoring the process identifier pid file output by the program to be monitored through an inotify mechanism of the Linux system.
In a third aspect, the present application provides a system-on-chip SOC provided on a vehicle, the SOC running a Linux system, the SOC comprising the program monitoring device of the second aspect.
In a fourth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which when executed by a system on a chip SOC implements the program monitoring method according to the first aspect; the SOC is arranged on the vehicle and runs a Linux system.
Compared with the prior art, the application has the following beneficial effects:
the program monitoring method is applied to a system on a chip on a vehicle, and the system on a chip runs a Linux system. Firstly, receiving a starting instruction sent by a system starter system of the Linux system; and when the starting instruction is started successfully, monitoring the process identifier pid file output by the program to be monitored. The program to be monitored cannot be started and managed by the system. When an exception occurs to the program to be monitored (such as a deadlock, crash or exit, etc.), the pid file output by the program will disappear. According to the method, the process identifier pid file output by the program to be monitored is monitored, and because the pid file carries the unique identifier of the program to be monitored, when the disappearance of the pid file carrying a unique identifier is monitored, the abnormality of the program to be monitored corresponding to the unique identifier can be determined. The abnormal condition of the program started by the nonsystemed can be timely obtained without changing the existing program starting logic, and the running safety of each program in the Linux system is improved.
Drawings
In order to more clearly illustrate the embodiments of the application or the technical solutions of the prior art, the drawings which are used in the description of the embodiments or the prior art will be briefly described, it being obvious that the drawings in the description below are only some embodiments of the application, and that other drawings can be obtained according to these drawings without inventive faculty for a person skilled in the art.
FIG. 1 is a flowchart of a program monitoring method according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a conventional program start logic in a Linux system;
FIG. 3 is a schematic diagram of a program start logic according to an embodiment of the present application;
FIG. 4 is a flowchart of another program monitoring method according to an embodiment of the present application;
FIG. 5 is a schematic diagram of another program start logic provided in an embodiment of the present application;
FIG. 6 is a schematic diagram of a program start logic provided by an embodiment of the present application;
fig. 7a is a schematic structural diagram of a program monitoring device according to an embodiment of the present application;
fig. 7b is a hardware configuration diagram of the program monitoring device according to the present embodiment.
Detailed Description
As described above, the system launcher system of the Linux system is only used to launch a part of the programs, and other programs (such as the image capturing application program and the radio application program) are not launched by the system and cannot be managed by the system. It can be appreciated that when an abnormality occurs in the program started by the system, the system can learn in time and take corresponding measures; however, the program started by the non-system is not known by the system even if an abnormality occurs due to lack of management of the system. Thus, the exception conditions that lead to Linux systems for these non-systematic initiated programs are difficult to respond in time.
Based on the problem, the application provides a program monitoring method, a device, a system on chip and a storage medium, which are used for determining whether an abnormality occurs in a program by monitoring the change of a process identifier pid file output by a program started by a non-system after the program is successfully started according to a starting instruction sent by the system.
In order to make the present application better understood by those skilled in the art, the following description will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
First embodiment
In this embodiment, a program monitoring method is provided. The method is applied to a System On Chip (SOC) arranged on a vehicle, and the SOC runs a Linux System to provide various services for users. As an example, the SOC can enable relevant services of an in-vehicle entertainment system. The entertainment system may specifically be referred to as a vehicle infotainment system (In-Vehicle Infotainment, IVI) having audio, navigation and bluetooth communication capabilities and having various interfaces, such as a USB interface. The entertainment system can run applications of radio, audio and video players, games, instant messaging, etc.
Referring to fig. 1, a flowchart of a program monitoring method according to an embodiment of the present application is shown.
As shown in fig. 1, the program monitoring method provided by the embodiment of the application includes:
step 101: and receiving a starting instruction sent by a system starter system of the Linux system.
In order to facilitate understanding of the improvement of the program monitoring method provided in the present embodiment, reference may be made to fig. 2 and 3, and fig. 2 is a schematic diagram of existing program start logic in a Linux system; fig. 3 is a schematic diagram of Linux system program start logic of the program monitoring method according to the embodiment of the present application.
As can be seen from FIG. 2, the system initiator system is responsible for initiating service, socket and Mount programs according to the existing program initiation logic in the Linux system. The program to be monitored in FIG. 2 is a non-systematic initiated program that is not systematic initiated and managed. Fig. 3 provides an alternative implementation, in which the system achieves monitoring of the program to be monitored by means of a monitoring program that performs the program monitoring method provided in this embodiment. In this embodiment, the monitoring program can be started by the system. In the program start logic illustrated in fig. 3, the system is responsible for starting not only the programs service, socket and Mount, but also the monitoring program. Specifically, when the system d needs to start the monitor, a start instruction is sent to the monitor. Thus, the monitoring program executing the method of the present embodiment is started according to the start instruction.
In practical application, the monitoring program is added to the Linux system in advance, and a starting item corresponding to the monitoring program is configured in the catalog of the system. When the system d needs to start the monitoring program to work, the system d triggers a start item corresponding to the monitoring program, so as to send a start instruction. And configuring a starting item corresponding to the monitoring program in the system d catalog to construct the starting relation between the system d and the monitoring program.
The monitoring procedure of the program to be monitored is specifically described below in connection with steps 102-103.
Step 102: and when the starting instruction is started successfully, monitoring the process identifier pid file output by the program to be monitored.
In practical applications, each program will output a process identifier (pid) file during execution. The file carries a unique identification of the program outputting the file. The pid file output by the program to be monitored carries the unique identifier of the program to be monitored. For example, the Linux system operates by a first program and a second program, wherein a unique identifier carried in a pid file output by the first program is id_1, and a unique identifier carried in a pid file output by the second program is id_2. If the second program is the program to be monitored, the second program is monitored according to the pid file with the unique identifier id_2 in the specific implementation.
Step 103: and when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal.
It will be appreciated that in practical applications, if the program to be monitored is running normally, the pid file of the program to be monitored will always exist, and once the program to be monitored is abnormal, such as deadlock, crash or exit, the pid file of the program to be monitored will disappear. Therefore, to monitor whether the program to be monitored is abnormal, specifically, the change of the pid file is monitored. And when the pid file is monitored to disappear, determining that the program to be monitored is abnormal.
Still using the above example, when the program to be monitored monitors that the pid file originally carrying the unique identifier id_2 suddenly disappears, the program to be monitored can determine that the second program is abnormal according to the corresponding relationship between the unique identifier and the program to be monitored, that is, the corresponding relationship between the id_2 and the second program.
The program monitoring method provided by the embodiment of the application is applied to the SOC of the system on a chip of the vehicle, and the SOC runs a Linux system. Firstly, receiving a starting instruction sent by a system starter system of the Linux system; and when the starting instruction is started successfully, monitoring the process identifier pid file output by the program to be monitored. The program to be monitored cannot be started and managed by the system. When an exception occurs to the program to be monitored (such as a deadlock, crash or exit, etc.), the pid file output by the program will disappear. According to the method, the process identifier pid file output by the program to be monitored is monitored, and because the pid file carries the unique identifier of the program to be monitored, when the disappearance of the pid file carrying a unique identifier is monitored, the abnormality of the program to be monitored corresponding to the unique identifier can be determined. The abnormal condition of the program started by the nonsystemed can be timely obtained without changing the existing program starting logic, and the running safety of each program in the Linux system is improved.
In practical applications, when an abnormality is detected in a program started by the nonsystemed, corresponding measures are required. To this end, another program monitoring method is provided in the embodiments of the present application. Specific implementations of the method are described below with reference to the examples and figures.
Second embodiment
Referring to fig. 4, a flowchart of another program monitoring method according to an embodiment of the present application is shown.
As shown in fig. 4, in this embodiment, the program monitoring method includes:
step 401: and receiving a starting instruction sent by a system starter system of the Linux system.
The implementation manner of step 401 in this embodiment is the same as that of step 101 in the foregoing embodiment, so the description of step 401 may refer to the foregoing embodiment, and will not be repeated here.
Step 402: and when the starting instruction is started successfully, reading the name of the program to be monitored carried by the environment variable in the system md directory.
Step 403: and determining a corresponding program to be monitored according to the name.
In practice, environment variables are configured for the monitor in advance in the systemd directory. The environment variable carries the name of the program to be monitored, which should be monitored after the monitoring program is started. In practical applications, one monitoring program may be used to monitor one program to be monitored, or one monitoring program may be used to monitor a plurality of programs to be monitored. If a monitoring program monitors a program to be monitored, the environment variable of the monitoring program carries the name of the program to be monitored; if the monitoring program monitors a plurality of programs to be monitored, the environment variable of the monitoring program carries the name of each program to be monitored.
In order to determine the program to be monitored, in this embodiment, after the monitoring program is started, the name of the program to be monitored carried by the environment variable needs to be read first. If there are multiple programs to be monitored, and one monitoring program is only used for monitoring one program to be monitored, the same number of monitoring programs as the number of the programs to be monitored can be added in the Linux system in advance. For example, three monitoring programs are added, namely, a monitoring program A1, a monitoring program A2 and a monitoring program A3, wherein the monitoring program A1 determines that the monitoring program A1 is used for monitoring the program B1 by reading the names of the programs to be monitored in the environment variables, the monitoring program A2 determines that the monitoring program A2 is used for monitoring the program B2 by reading the names of the programs to be monitored in the environment variables, and the monitoring program A3 determines that the monitoring program A3 is used for monitoring the program B3 by reading the names of the programs to be monitored in the environment variables. The program start logic diagram for this implementation is shown in fig. 5. In the program starting logic illustrated in fig. 5, the system d is responsible for starting up not only the programs service, socket and Mount, but also the monitoring programs A1, A2 and A3, and when the monitoring programs A1, A2 and A3 are started up by the system md, they can be used for monitoring the programs B1, B2 and B3 to be monitored respectively.
If a plurality of programs to be monitored need to be monitored, one program to be monitored can be used for monitoring the plurality of programs to be monitored, one program to be monitored can be added in the Linux system in advance. For example, the added monitoring program is A4, and the name of the program to be monitored in the environment variable is read to determine that the program is used for monitoring the programs to be monitored B4, B5 and B6. The program start logic diagram for this implementation is shown in fig. 6. In the program start logic illustrated in fig. 6, the system is responsible for starting up not only the programs service, socket and Mount, but also the monitor program A4, and when the monitor program A4 is started up by the system, it can be used to monitor the programs B4, B5 and B6 to be monitored.
Step 404: monitoring a process identifier pid file output by a program to be monitored through an inotify mechanism of the Linux system, and executing a step 405 when the pid file is monitored to be created; when the pid file is monitored to disappear, step 406 is performed.
The inotify mechanism is a change notification mechanism of a file system in a Linux kernel, and can monitor that various files are created or deleted. In this embodiment, the program to be monitored is monitored according to the pid file through an inotify mechanism. If the pid file carrying the unique identification of the program to be monitored is monitored, namely the pid file of the program to be monitored is created from scratch, the program to be monitored is successfully started. If the pid file carrying the unique identifier of the program to be monitored is monitored, the pid file of the program to be monitored disappears (is deleted), which indicates that the program to be monitored is abnormal in running.
Step 405: and when the pid file is detected to be created, determining that the program to be monitored is successfully started.
Step 406: when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal, and restarting the program to be monitored.
When the program to be monitored is determined to be abnormal, the program to be monitored needs to be restarted in order to restore the normal operation of the program to be monitored. It can be understood that, after the program to be monitored is restarted, the program monitoring method provided in this embodiment may be continuously executed to continuously monitor the program to be monitored. That is, the change of the pid file after restarting the program to be monitored can be monitored through the inotify mechanism, if the pid file is not created after restarting or disappears again after the pid file is created, the restart failure of the program to be monitored is indicated, and the restart is performed again until the restart is successful.
The above embodiment monitors the change of the pid file of the program to be monitored through the existing inotify mechanism of Linux, and is convenient, reliable and simple to implement. After the abnormality of the program to be monitored is determined, restarting the program to be monitored, and ensuring that the program started by the non-system in the Linux system is recovered to normal operation. According to the embodiment, the method for monitoring the program to be monitored is realized, and program management of the Linux system is not complicated, so that the stability and the robustness of the Linux system are ensured while the program is monitored.
Based on the program monitoring method provided by the foregoing embodiment, correspondingly, the application further provides a program monitoring device. Specific implementations of the apparatus are described below with reference to the examples and figures.
Third embodiment
Referring to fig. 7a, a schematic structural diagram of a program monitoring device according to the present embodiment is shown. The device is applied to a system-on-chip (SOC) arranged on a vehicle, and the SOC runs a Linux system.
As shown in fig. 7a, the program monitoring device provided in this embodiment includes:
a start-up instruction receiving module 71, configured to receive a start-up instruction sent by a system starter system of the Linux system;
the file monitoring module 72 is configured to monitor a process identifier pid file output by the program to be monitored when the start-up is successful according to the start-up instruction; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored;
and the program monitoring module 73 is used for determining that the program to be monitored is abnormal when the pid file is monitored to disappear according to the unique identification.
The device monitors the process identifier pid file output by the program to be monitored, and because the pid file carries the unique identifier of the program to be monitored, when the pid file carrying a unique identifier is monitored to disappear, the abnormality of the program to be monitored corresponding to the unique identifier can be determined. The device can timely acquire the abnormal condition of the program started by the nonsystemed without changing the existing program starting logic, and improves the running safety of each program in the Linux system.
In practical applications, when an abnormality is detected in a program started by the nonsystemed, corresponding measures are required. For this reason, the program monitoring device provided in this embodiment further includes:
and the program restarting module is used for restarting the program to be monitored.
Optionally, the program monitoring module 73 is further configured to determine that the program to be monitored is successfully started when it is monitored that the pid file is created.
Optionally, the program monitoring device further includes:
the program name reading module is used for reading the name of the program to be monitored carried by the environment variable in the system md directory;
and the program determining module is used for determining a corresponding program to be monitored according to the name.
The environment variables are preconfigured. The name of the program to be monitored, which is carried in the environment variable and read by the program name reading module, indicates that the program monitoring device needs to correspondingly monitor the program to be monitored. Thus, the program determining module can determine the program to be monitored of the device to be monitored.
Optionally, the file monitoring module 72 specifically includes:
and the first monitoring unit is used for monitoring the process identifier pid file output by the program to be monitored through an inotify mechanism of the Linux system.
The device monitors the change of the pid file of the program to be monitored through the existing inotify mechanism of Linux, and is convenient, reliable and simple to realize. After determining that the program to be monitored is abnormal, the device restarts the program to be monitored, and ensures that the program started by the nonsystemed in the Linux system can be restored to normal operation. The program monitoring device provided by the application does not excessively complicate the program management of the Linux system, so that the stability and the robustness of the Linux system are ensured while the program monitoring is carried out.
Based on the program monitoring method and the program monitoring device provided by the foregoing embodiments, correspondingly, the application further provides a system on a chip. Specific implementations of the system-on-chip are described below in connection with embodiments.
Fourth embodiment
The system on chip SOC provided in the present embodiment is disposed on a vehicle, and the SOC runs a Linux system, and includes the program monitoring device provided in the third embodiment.
The SOC is used for receiving a starting instruction sent by a system starter system of the Linux system; when the starting instruction is started successfully, monitoring a process identifier pid file output by a program to be monitored; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored; and when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal.
The SOC monitors a process identifier pid file output by a program to be monitored, and because the pid file carries a unique identifier of the program to be monitored, when the pid file carrying a unique identifier is monitored to disappear, the program to be monitored corresponding to the unique identifier can be determined to be abnormal. The SOC can timely acquire the abnormal condition of the program started by the nonsystemed without changing the existing program starting logic, and improves the running safety of each program in the Linux system.
Optionally, the SOC is further used to restart the program to be monitored.
Optionally, the SOC is further configured to determine that the program to be monitored is successfully started when it is monitored that the pid file is created.
Optionally, the SOC is further configured to read a name of a program to be monitored carried by an environment variable in the systemd directory; and determining a corresponding program to be monitored according to the name.
Optionally, the SOC is specifically configured to monitor, by using an inotify mechanism of the Linux system, a process identifier pid file output by a program to be monitored.
The SOC monitors the change of the pid file of the program to be monitored through the existing inotify mechanism of Linux, and is convenient, reliable and simple to realize. After the program to be monitored is determined to be abnormal, the SOC can restart the program to be monitored, so that the program started by the non-system md in the Linux system can be ensured to be restored to normal operation. Because the SOC provided by the application does not change the program management of the Linux system to be too complex, the stability and the robustness of the Linux system are ensured while the program is monitored.
In addition, based on the program monitoring method, the program monitoring device and the system on chip provided by the foregoing embodiments, correspondingly, the application further provides a computer readable storage medium. The medium has stored thereon a computer program which when executed by a system on a chip SOC implements the program monitoring method as provided by the foregoing embodiments.
The system on chip may specifically be a system on chip provided by the foregoing embodiments. The storage medium may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as Static Random Access Memory (SRAM), NAAD flash, NOR flash, eMMc, SD. The specific type of the storage medium provided in the present embodiment is not limited here.
Based on the system on chip and the storage medium provided by the foregoing embodiments, the present application further provides a program monitoring device.
Referring to fig. 7b, the hardware configuration diagram of the program monitoring device provided in this embodiment is shown.
As shown in fig. 7b, the program monitoring device includes: a storage medium 701, a system on a chip 702, a communication bus 703 and a communication interface 704.
The storage medium 701 stores a program that can run on a system on a chip, and when the program is executed, part or all of the steps in the program monitoring methods provided in the first embodiment and the second embodiment of the present application are implemented.
In the program monitoring device, the system on chip 702 and the storage medium 701 transmit signaling, logic instructions, and the like through the communication bus 703. The program monitor device is capable of communicating with other devices via the communication interface 704.
By executing the method by the program, the condition that the program to be monitored is abnormal, such as deadlock, crash or exit, can be determined. The program monitoring equipment monitors the program to be monitored, does not change the existing program starting logic, enables the Linux system to timely acquire the abnormal condition of the program started by the nonsystemed, and improves the running safety of each program in the Linux system.
The application further provides a vehicle based on the program monitoring method, the program monitoring device, the system on chip, the storage medium and the program monitoring equipment provided by the embodiment. The vehicle comprises the system on a chip, so that the vehicle can also determine that the program to be monitored is abnormal, such as deadlock, breakdown or exit, by using the SOC of the system on a chip. The SOC of the vehicle monitors the program to be monitored, the abnormal condition of the program started by the non-system can be timely obtained without changing the existing program starting logic, and the running safety of each program in the Linux system is improved. Thus, the vehicle can provide more stable service to the user.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part. The above-described apparatus and system embodiments are merely illustrative, in which elements illustrated as separate elements may or may not be physically separate, and elements illustrated as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present application without undue burden.
The foregoing is only one specific embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions easily contemplated by those skilled in the art within the technical scope of the present application should be included in the scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims (5)
1. The program monitoring method is characterized by being applied to a System On Chip (SOC) arranged on a vehicle, wherein the SOC runs a Linux system, the method is applied to a monitoring program, the monitoring program is added into the Linux system in advance and is used for being started by a system starter system, and a starting item corresponding to the monitoring program is configured in a catalog of the system; the method comprises the following steps:
receiving a starting instruction sent by a system starter system of the Linux system; the starting instruction is sent after the system triggers a starting item corresponding to the monitoring program;
when the starting instruction is started successfully, monitoring a process identifier pid file output by a program to be monitored; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored;
when the pid file output by the program to be monitored is detected to be created, determining that the program to be monitored is successfully started;
when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal, and restarting the program to be monitored until the program to be monitored is restarted successfully;
and before the process identifier pid file output by the program to be monitored is monitored, the method further comprises the following steps:
reading the name of a program to be monitored carried by an environment variable in a system d catalog; the environment variables are pre-configured in the systemd directory for the monitor;
and determining a corresponding program to be monitored, which needs to be monitored, according to the name.
2. The method according to claim 1, wherein the monitoring of the process identifier pid file output by the program to be monitored comprises:
and monitoring a process identifier pid file output by a program to be monitored through an inotify mechanism of the Linux system.
3. The program monitoring device is characterized by being applied to a System On Chip (SOC) arranged on a vehicle, the SOC runs a Linux system, the device is applied to a monitoring program, the monitoring program is added into the Linux system in advance and is used for being started by a system starter system, and a starting item corresponding to the monitoring program is configured in a catalog of the system; the device comprises:
the starting instruction receiving module is used for receiving a starting instruction sent by a system starter system of the Linux system; the starting instruction is sent after the system triggers a starting item corresponding to the monitoring program;
the file monitoring module is used for monitoring a process identifier pid file output by a program to be monitored when the starting is successful according to the starting instruction; the program to be monitored is a program started by the system; the pid file carries a unique identifier of the program to be monitored;
the program monitoring module is used for determining that the program to be monitored is successfully started when the pid file output by the program to be monitored is detected to be created; when the pid file is monitored to disappear according to the unique identifier, determining that the program to be monitored is abnormal;
the apparatus further comprises:
the program restarting module is used for restarting the program to be monitored until the program to be monitored is restarted successfully;
further comprises:
the program name reading module is used for reading the name of the program to be monitored carried by the environment variable in the system md catalog before the process identifier pid file output by the program to be monitored is monitored; the environment variables are pre-configured in the systemd directory for the monitor;
and the program determining module is used for determining a corresponding program to be monitored, which needs to be monitored, according to the name.
4. A system on a chip characterized in that a system on a chip SOC is provided on a vehicle, said SOC running a Linux system, said SOC comprising the program monitoring device of claim 3.
5. A computer readable storage medium, characterized in that the medium has stored thereon a computer program, which when executed by a system on a chip SOC implements the program monitoring method according to any of claims 1-2; the SOC is arranged on the vehicle and runs a Linux system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910610708.1A CN110389878B (en) | 2019-07-08 | 2019-07-08 | Program monitoring method, device, system on chip and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910610708.1A CN110389878B (en) | 2019-07-08 | 2019-07-08 | Program monitoring method, device, system on chip and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110389878A CN110389878A (en) | 2019-10-29 |
| CN110389878B true CN110389878B (en) | 2023-10-27 |
Family
ID=68286377
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910610708.1A Active CN110389878B (en) | 2019-07-08 | 2019-07-08 | Program monitoring method, device, system on chip and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110389878B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106775981A (en) * | 2016-12-15 | 2017-05-31 | 北京奇虎科技有限公司 | A kind of process handling method, device and computer-readable medium |
| CN107291510A (en) * | 2017-06-30 | 2017-10-24 | 惠州华阳通用电子有限公司 | A kind of Linux inter-vehicle information systems quick start method |
| CN108415736A (en) * | 2018-02-06 | 2018-08-17 | 新浪网技术(中国)有限公司 | The method, apparatus and equipment of program process are marked using process filesystem |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016015220A1 (en) * | 2014-07-29 | 2016-02-04 | Hewlett-Packard Development Company, L.P. | Executable code abnormality detection |
| US20170153930A1 (en) * | 2015-11-30 | 2017-06-01 | Coreos, Inc. | Application container runtime |
-
2019
- 2019-07-08 CN CN201910610708.1A patent/CN110389878B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106775981A (en) * | 2016-12-15 | 2017-05-31 | 北京奇虎科技有限公司 | A kind of process handling method, device and computer-readable medium |
| CN107291510A (en) * | 2017-06-30 | 2017-10-24 | 惠州华阳通用电子有限公司 | A kind of Linux inter-vehicle information systems quick start method |
| CN108415736A (en) * | 2018-02-06 | 2018-08-17 | 新浪网技术(中国)有限公司 | The method, apparatus and equipment of program process are marked using process filesystem |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110389878A (en) | 2019-10-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10191811B2 (en) | Dual boot computer system | |
| US20150074386A1 (en) | Boot method and boot system | |
| WO2010098019A4 (en) | Program update device, program update method, and information processing device | |
| CN107291510B (en) | Rapid starting method for Linux vehicle-mounted information system | |
| US8924769B2 (en) | Software burning system and burning control method | |
| US10146626B2 (en) | Detecting and handling an expansion card fault during system initialization | |
| CN109361542B (en) | Client fault processing method, device, system, terminal and server | |
| US9208320B2 (en) | Software distribution system and software distribution method | |
| CN112416411B (en) | Upgrading method and device, equipment end, server and computer readable medium | |
| CN101593122B (en) | Method and device for starting embedded system | |
| CN114172803B (en) | Multi-FPGA version control and configuration system and method based on Ethernet switching technology | |
| CN110389878B (en) | Program monitoring method, device, system on chip and storage medium | |
| CN106028142A (en) | Upgrading control method and upgrading control apparatus for playing devices | |
| CN105791514B (en) | Application starting monitoring method and device | |
| CN114237722B (en) | System starting method, device, equipment and engineering vehicle | |
| FR3003365A1 (en) | METHOD AND DEVICE FOR MANAGING SOFTWARE UPDATES OF A SET OF EQUIPMENT OF A SYSTEM SUCH AS A SYSTEM OF AN AIRCRAFT | |
| JP6237543B2 (en) | In-vehicle device | |
| WO2016000355A1 (en) | Terminal upgrade method and device | |
| KR20210113595A (en) | Anomaly handling method, terminal device and storage medium | |
| CN113157481A (en) | Cluster-based server jump time fault processing method, device and system | |
| CN110442467B (en) | Data sharing method, terminal and computer readable storage medium | |
| CN103473081A (en) | Operant method after system updating of terminal and terminal | |
| JP2016024802A (en) | Write-in circuit and write-in method for basic input/output system program code | |
| CN112905218B (en) | Firmware upgrading method, device and equipment | |
| CN110764940A (en) | Processing method and device for service exception of distributed system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |