Linux Process kill and crash-proof monitor implementation

For many self-implemented services, many people prefer to use a dedicated monitoring process to monitor their own services. To prevent the monitoring process from collapsing, they even use classic dual-process monitoring. Not to mention anything else, writing and debugging this dual process is enough for me to have a pot of tea. It is a tough task for me to write bugs like this. Even one day, I will not write any bugs, but you will not be able to go through the operating system level, and there will be a lot of difficulties. These monitoring programs, whether single-process or dual-process, must be a big loop, and almost all of this big loop must have a sleep; otherwise, the CPU will soar, but you don't have to provide real services. If you give this big loop, even if you don't have sleep, you have a lot of CPU cores and don't care about the money, you can buy a dedicated CPU to run your monitor big
Loop, but there are still many things that can happen in the tiny gap between this detection and the next detection. For example, the following dual-process sequence:View
Plain

1. P1: While (true) {: t0
2. Status = Monitor (P2): T1
3. If (status = 0 ){
4. Start (P2 );
5. }
6. }: T2
7. P2: While (true) {: t0'
8. Status = Monitor (P1): t1'
9. If (status = 0 ){
10. Start (P1 );
11. }
12. }: T2'

Most directly, assume that P1 and P2 run on two CPUs simultaneously, and the sequence is synchronized between T0 and T1, between T0 and T1, what will happen when P1 and P2 are killed? If it is run on the same CPU, the task is simpler. When P1 is killed between t1 and t2, sigkill is sent to P2, at this time, the OS is scheduled to P2, and P2 should have been running from t0. However, because sigkill exists in the kernel signal queue, it will exit directly, and who will start them later. Operating System Scheduling cannot be controlled by programmers and administrators, and it does not export more control to the application layer. Therefore, with a single CPU, you cannot predict how the scheduler will schedule your monitor, so you can design a chaotic sequence to constantly try to kill your dual monitor. With more CPUs, the problem is worse, you are destined to dance with your feet.

Therefore, dual-process protection is not logically desirable, although it is generally used in general scenarios. The problem is that P1 or P2 can be killed at any time. If one of them will not be killed, the problem will be solved. In Linux, The INIT process cannot be killed, so init can be used as the monitor. In fact, there is also a classic big loop in it, but people have the privilege, so a lot of sleep is not a problem. In fact, many Linux services use the INIT process as their own monitor. You only need to edit/etc/inittab. In this inittab, note the last few rows: 1: 2345: respawn:/sbin/mingetty tty1...

The meaning of this respawn is to end up again. You just need to add a few more lines of such information, and your service will be monitored. Note that the rows are separated by commas (,). The first field is a unique ID, which can be extended. The specific information can be man inittab, which will be clear at a glance, I will not translate man's manual.

Http://blog.csdn.net/dog250/article/details/6992886

Author: feiskyer published on 21:32:13 Original article link reading: 17 comment: 0 view comment