What should I pay attention to when I restart a Unix server?

It is no longer easy for system administrators to manage their own servers, but it is not easy to manage the servers. Restarting the server is not a joke for administrators. For Windows server administrators, restarting Windows devices on a regular basis has become a norm of life, but this approach is hard to work in Unix systems-by default, restarting does not bring about any improvement.

I plan to take this opportunity to discuss the restart issue in detail. This is a hot topic for every server administrator, however, Unix geeks see it as a deeper topic-probably because Windows administrators often regard restart as one of the first steps for troubleshooting, however, the Unix team only tries to solve the problem.

Two cases of Unix Server restart

The actual situation is: Server restart operations should rarely occur-please note that there are very few. Here I will list Kernel updates and hardware replacement as examples, because they are two major reasons for restarting in the Unix field. Some people have been advocating serious security risks if they do not restart the server. If security risks exist in service projects and applications, you can fix the problem by applying a vulnerability patch, and the patch usually does not require device restart. If the security risk exists in the kernel module, you only need to uninstall the corresponding module, install patches, and re-load the module. Yes, I admit that once there is a security risk in the kernel, the restart operation is indeed necessary. However, in this case, there is no real reason to restart the Unix server.

Some people think that if the restart operation is not performed, other forms of risks will often come one after another. For example, some key service projects are not properly enabled at startup, which will lead to a series of risks. Of course, this statement is correct, but as long as the management work is in place, it is simply a matter of worry. Only the cainiao who just took over the server will forget to set the startup parameters of the Service Project correctly. However, if your server is in the construction phase and does not involve any production content, you may wish to perform various restart tests without any adverse effects. And I think this is the best time to get familiar with the restart mechanism.

But there is another need to consider: those who take the restart operation as one of the important steps for troubleshooting are not afraid of boiling water, and intend to expose all the problems at one time. Let's talk about a set of Unix devices that have encountered problems. Some services that are still running cannot be started again, this will be apparent after the restart-maybe due to segment failure or other strange reasons.

Causes of Unix Server restart

If we just want to check the device and decide to restart it a few minutes later, the real cause of the failure may be completely lost in time-maybe a junior administrator accidentally deleted the/boot directory or/etc,/usr when running a stupid script written by himself. /lib64 directory. This is the cause of segmentation failure and equipment instability. However, once we choose to directly restart the server without in-depth mining, the problem will obviously become more serious, in the next few cases, you should start restoring the image-which means you need to deal with a lot of recovery work-and the production server will also be shut down.

The above is only one of the reasons we should try to avoid restarting operations in the Unix field. This is not so much a troubleshooting method as a type of desperate bet-either discovering a problem or destroying everything and then rebuilding it slowly. In short, no one can use the/var partition to restart the device and the error is completely corrected. (In addition, please do not mention the peatness of opening file handles-I think everyone should understand what I mean)

Please do your work before restarting the server

In most cases, it is extremely important not to restart, because the key content in the system that can help us fix the problem exists before the restart, however, it may not remain after the restart. After the restart, the problem will definitely occur again. However, once the solution disappears with the restart, the fault itself will be stuck in an endless loop. Unless someone decides not to restart, but tries to find out the root cause of the problem. Unfortunately, few people can make such a wise choice. The actual situation is: a small faulty memory can bring great trouble to the normal operation of the system and the startup status of the device. At this time, the right remedy is the best strategy. Simply restarting will only cause additional losses.

Therefore, in the future, if a guy says "hey, you might as well restart it first. Restarting is of course one of the solutions, but before implementing the restart, make sure that we have taken all the measures we can think of. After all, all we have saved is our own time and energy.