-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 5.1.0-rc3
-
Component/s: None
-
Fully Compatible
-
ALL
-
-
Security 2021-12-13
-
135
In a07dc7, the code for `mongod --shutdown` was refactored, and appears to have inadvertently changed from `while (boost::filesystem::exists(procPath))` to `while (boost::filesystem::exists(pidfile))`, which never becomes false as the `mongod.lock` file this new version is waiting for is only ever emptied, not deleted.
This fixes that to wait for the file to be either deleted or emptied. I debated switching back to `procPath` like the previous code, but I figured maybe it was changed on purpose? I'm not sure how that previous change was tested, though.
The difference between the behavior currently in 5.0 and this new implementation is that the old `--shutdown` would exit even if the server exited uncleanly (because it was waiting for the PID to no longer exist) while the new implementation would instead hang forever (which is what happens on the 5.1 RCs when you run `mongod --shutdown` whether the server shuts down or not, and how I discovered this issue).
I'll add my standard disclaimer that I'm happy to adjust, rebase, amend, etc this change in any way. :smile:
Original Summary
mongod --shutdown" hangs forever
Original Description
In a07dc78, the code for mongod --shutdown was refactored, and appears to have inadvertently changed from while (boost::filesystem::exists(procPath)) to while (boost::filesystem::exists(pidfile)), which never becomes false as the mongod.lock file this new version is waiting for is only ever emptied, not deleted.
I've got a PR open at https://github.com/mongodb/mongo/pull/1428
- is related to
-
SERVER-56677 Coverity analysis defect 119556: Untrusted loop bound
-
- Closed
-