Shulou(Shulou.com)06/02 Report--

1. Error message description

During the equipment inspection in Wanzhou, Chongqing, it was found that the terminal window of CCS01A (HP UNIX B.11.31) server frequently popped up with errors. The output information of dmesg and OLDsyslog.log were all the information of the error and the / var partition was full, but syslog.log was no longer written into content a long time ago, and it was an empty file.

# error messages frequently reported in the terminal window esmd: System Error: The EVM daemon has failed and cannot be restarted

The solution to the problem that 2.syslog.log is an empty file

After the syslogd service is restarted, the relevant error information such as esmd: System Error: The EVM daemon has failed and cannot be restarted starts to be written to the log file.

The solution of frequent error reports in 3.evm daemon

Event Management (EVM)

Execute the command on a normal server:

Ps-ef | grep evm*

You can get the following results, but there is no process for evm on the CCS01A (error server):

Manually execute the command to start the evmd process:

/ usr/sbin/evmd

Check again that the process already exists on CCS01A and the server no longer reports an error.

However, the evmlogger and evmchmgr related processes similar to the normal server are not started. The evmlogger and evmchmgr related commands are manually executed according to the commands displayed by the normal server process, and the server reports an error:

Interpreter "/ bin/sh" not found

Compared with the normal server, it is found that there is a soft link for: / bin-> / usr/bin on the normal server, but not on CCS01A, so create a new soft link on CCS01A and modify its master and group:

Ln-s / usr/bin / binchown-h bin:bin / bin

After modification, the CCS01A evm-related service starts normally, and the server can start it automatically immediately after shutting down the evmd service.

It is recommended to manually enable and disable the evmd service (in fact, under normal circumstances, the service will be automatically started as soon as it is disabled):

Evmstopevmstart can also be: / sbin/init.d/evm stop/sbin/init.d/evm start4. Record of tangled troubleshooting process

First of all, the solution found online is:

If you have same issue you can try to Copy evmstart and evmstop scripts from the good host. Then the issue is solved.

In other words, you can copy the evmstart and evmstop files of the normal server to the server that reported the error. You can use the following command to find these two files:

Find /-name evmstartfind /-name evmstop

First, back up the original files of the CCS01A server, and then copy the normal files to CCS01A, and pay attention to modifying the master group and permissions of the files.

But I found that CCS01A still reported an error after copying the correct file, so I looked at the evm-related processes on the normal server:

Ps-ef | grep evm*

It is found that there is a process on the normal server: / usr/sbin/evmd process, but not on CCS01A, so open the process on CCS01A and execute the command:

/ usr/sbin/evmd

Check again that the process already exists on CCS01A, and the server no longer reports an error, and then search for the method of enabling and shutting down the evmd service, as follows:

# HP UNIX method to restart the evmd service: # method 1: / sbin/init.d/evm stop / sbin/init.d/evm start# method 2 (method 1 should be formal): kill the evmd process kill-9 PID execute command / usr/sbin/evmd# method 3 (this method is seen in the / sbin/init.d/evm script): evmstop evmstart

Thinking that this would completely solve the problem, I decided to restart the evmd service on a whim. As a result, frequent errors occurred again, and the evmd service could not be started using the / sbin/init.d/evm start command. The restart process is shown in the following figure:

Then look at the / sbin/init.d/evm file and find that the script recommends using evmstart and evmstop to manually enable and disable the evmd service, and the script also calls these two commands, so execute evmstart to open the evmd service, and the result is still an error:

The / bin/sh cannot be found in the error report. Look at the evmstart script and find that the command interpreter specified at the beginning of it is: #! / bin/sh. Execute the command in the terminal window: the result of which sh is: / usr/bin/sh, other normal servers are: / bin/sh

Here we begin to subjectively assume that the normal server sh command is in the / bin/sh directory, while the error CCS01A causes the sh to be in the / usr/bin directory for unknown reasons

Then modify the command interpreter at the beginning of the evm*-related script under the / usr/sbin directory to: #! / usr/bin/sh. After executing evmstart again, the evmd service starts normally and restarts:

Evmstopevmstart or / sbin/init.d/evm stop / sbin/init.d/evm start

The system no longer reports an error. In fact, after shutting down the service, the system will automatically turn it on soon. There is no need to manually open the evmd service. See the following figure:

Finally, compared with the normal server, it is found that there are fewer evm processes on CCS01A, and the normal server processes are as follows:

Therefore, the evmlogger and evmchmgr related commands are executed manually according to the commands displayed by the normal server process, and the server reports an error:

Interpreter "/ bin/sh" not found

Compared with the normal server, it is found that there is a soft link for: / bin-> / usr/bin on the normal server, but not on CCS01A, so create a new soft link on CCS01A and modify its master and group:

# create a new soft link ln-s / usr/bin / binchown-h bin:bin / bin

After modification, the CCS01A evm-related service starts normally, and the server can start it automatically immediately after shutting down the evmd service. So far, the error has been resolved successfully.

5. Description of other problems

About the path of the command interpreter:

Execute the command in the CCS01A terminal window: the result of which sh is: / usr/bin/sh, other normal servers are: / bin/sh

This can be explained by the order in which the system command paths are displayed with the which command:

The which command searches for the location of a system command in the path specified by the PATH variable and returns the first search result. That is, using the which command, you can see whether a system command exists and where the command is being executed.

After CCS01A has created the soft link, you only need to modify the current PATH variable to make it consistent with the path displayed by other servers:

PATH=/bin:$PATH

In order to avoid other effects, the PATH variable of CCS01A is not modified this time.

Another solution found on the Internet is as follows, but the problem was not solved after the experiment, and this method is now listed for reference only:

Hello freinds,Above mentioned problem is solved.Problem was solved by this way-Ensure that there is softlink between / directory to the directory which contains evmstop and evmstop script files.Command i used isln-s / usr/bin2 / Thanks for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.