Safely stop NodeOS

problem

kill When the command is executed again, it will cause the following error .

pkill -9 nodeos or kill -9 {pid} database dirty flag set (likely due to unclean shutdown): replay required

When re running nodeos when , You have to use --replay-blockchain Command to rebuild system data .

test

Here is How do I stop nodeos gracefully? · Issue #4301 · EOSIO/eos · GitHub Stop of summary nodes Test results

This appears to be two different issues. Startup after a crash or ungraceful shutdown nearly always fails due to corruption of the boost shared memory cache of the in-memory database. --resync is required to clean up the mess. For normal shutdown, never kill with -9. Always use either the default (no argument) signal (which is SIGTERM) or SIGINT. Numerically, those are 15 and 2, respectively. pkill nodeos | Safe pkill -15 nodeos | Safe pkill -2 nodeos | Safe pkill -TERM nodeos | Safe pkill -SIGTERM nodeos | Safe pkill -INT nodeos | Safe pkill -SIGINT nodeos | Safe pkill -9 nodeos | Not Safe pkill -KILL nodeos | Not Safe pkill -SIGKILL nodeos | Not Safe The core dump is a different problem. That looks like a corrupted network packet, specifically a signed_block_summary. Summary messages are being eliminated from the protocol, so this particular error will no longer be possible soon.  

summary

Simple command to safely stop the process ：

pkill nodeos

Reference from ：github

scene 2：docker

Safety method

• If nodeos The runner docker In container , According to the test above , You can know that the following methods are safe

docker kill -s SIGTERM [nodeos Container name ]

• docker exec pkill nodeos It's safe

docker kill -s SIGTEM Is reliable

By default ,docker kill The command does not give any... To applications in the container gracefully shutdown The opportunity of . It will send out directly SIGKILL System signal , To forcibly terminate the operation of the program in the container .

# docker kill --help Usage: docker kill [OPTIONS] CONTAINER [CONTAINER...] Kill one or more running containers Options: -s, --signal string Signal to send to the container (default "KILL")

But it can go through -s Options

docker kill -s Signal name 【 Container name 】 docker kill -s SIGTERM mycontainer

docker stop- unreliable

stay docker stop When the command is executed , Will first put into the container PID by 1 The process of sending system signals SIGTERM, Then wait for the application in the container to terminate execution , If the waiting time reaches the set timeout , Or by default 10 second , Will continue to send SIGKILL The system signal is forced kill Drop the process . Applications in containers , You can choose to ignore and not deal with SIGTERM The signal , But once the timeout is reached , The program will be forced by the system kill fall , because SIGKILL The signal is sent directly to the system kernel , The application has no chance to deal with it . In the use of docker stop When ordered , The only thing we can control is the timeout , For example, set to 20 Second timeout :

# docker stop --help Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...] Stop one or more running containers Options: -t, --time int Seconds to wait for stop before killing it (default 10)

-t： The time limit for closing the container , If the timeout fails to close, use kill closed , The default value is 10s, This time is used for the container's own saved state  

docker restart

Closing phase and docker stop Machine style .

Source code analysis

stay eos Project documents \eos\libraries\appbase\application.cpp Can be seen in ,nodeos Can pass 3 A signal SIGINT, SIGTERM, SIGPIPE To safely close the program . We usually use SIGTERM Just fine .

void application::setup_signal_handling_on_ios(boost::asio::io_service& ios) { std::shared_ptr<boost::asio::signal_set> ss = std::make_shared<boost::asio::signal_set>(ios, SIGINT, SIGTERM, SIGPIPE); wait_for_signal(ss); }