The shell starts the MONGO process by MONGO Args &, exits the shell after re-login and discovers that the MONGO process is gone, and the view log finds the following output:
2015-06-18t18:39:58.593+0800 [Signalprocessingthread]got signal 1 (hangup), would terminate after current CMD ends
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] now exiting
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] Dbexit:
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:going to close listening sockets ...
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] closing listening socket:8
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] closing listening socket:10
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] removing socket file:/tmp/mongodb-27017.sock
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:going to flush diaglog ...
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:going to close sockets ...
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:waiting for FS preallocator ...
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:lock for final commit ...
2015-06-18t18:39:58.593+0800 [Signalprocessingthread] shutdown:final commit ...
2015-06-18t18:39:58.603+0800 [Replslave] repl:assertionexception dbclient error communicating with server: 172.19.2.176:27017
2015-06-18t18:39:58.615+0800 [Signalprocessingthread] shutdown:closing All Files ...
2015-06-18t18:39:58.642+0800 [Signalprocessingthread] Closeallfiles () finished
2015-06-18t18:39:58.642+0800 [Signalprocessingthread] journalcleanup ...
2015-06-18t18:39:58.642+0800 [Signalprocessingthread] Removejournalfiles
2015-06-18t18:39:58.643+0800 [Signalprocessingthread] shutdown:removing FS lock ...
2015-06-18t18:39:58.643+0800 [Signalprocessingthread] dbexit:really exiting now
You can see that there are other processes that send hangup information to MONGO, just as kill -1 pid
you can confirm that no one is manually signaling to the MongoDB process, and Google found this post
The reasons are broadly as follows:
Bash resends a SIGHUP to all jobs if it receives a SIGHUP itself; This would include Mongod.
Also, if happen to has huponexit turned on, every job would receive a SIGHUP when bash exits.
Https://www.gnu.org/software/bash/manual/html_node/Signals.html
I used the shell to launch the MONGO, and then quit the shell to use the way is to directly close the window, Linux think this is an abnormal exit, so that the shell process will receive the SIGHUP signal, in order to ensure state consistency, The sighup signal is sent to all its child processes. This is not a problem if you exit with the command exit, because Linux will assume that this is a normal exit
So how do you avoid this problem? Close the window directly may be a habit of many people (bad habits), so we can not ask the Linux administrator to always do this, it is possible for people to make mistakes, should fundamentally solve the problem
Viewing the MongoDB Official document will find that MONGO has a parameter such as –fork, when starting MONGO with this parameter, it will automatically be suspended to the init process (PID 1) Start, without adding the PPID (parent process ID) is the current shell process, so just add- The fork problem is solved by the edge, and it is important to note that all programs that need to be run in the background need to be aware of the situation and be sure to do so in a way like mongo–fork
For more on Linux signal (signal) and bash please pay attention to man bash
Remember a "weird" MongoDB process Exit Event