[SERVER-24916] Only get current working directory (cwd) when necessary Created: 06/Jul/16 Updated: 07/Jul/16 Resolved: 07/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The expectation is that, in cases where the cwd isn't needed (which is the common case), any problem with it should not impact the ability of the server to successfully start. For situations where cwd problems can prevent startup, see getcwd() is called from setupCwd(), which sets serverGlobalParams.cwd. This variable is only used in two places: This means there are situations where a problem with the cwd can inhibit server startup, even though the cwd is utterly irrelevant and never actually used. One solution would be to rearrange the code so that:
There are a few ways of doing this, but I think a better fix would be:
|
| Comments |
| Comment by Kevin Pulo [ 07/Jul/16 ] |
|
No, that was never the intention. Situations where the server needs the cwd, but is unable to get it, would still fail immediately at startup. Situations where the server doesn't need the cwd, the server would start and run just fine, because it would never notice the problem with cwd (since by definition it isn't used). The motivation was that if the user has specified an absolute dbpath and logpath, then why should the server care what the cwd is? Or if it's not able to be known? It seemed silly to fail to start because something which was apparently never used couldn't be found. Although the two listed places are the only places where serverGlobalParams.cwd are used, there are actually other places which can call getcwd() at later times during the dynamic extent, via boost::filesystem::absolute (without passing in a base dir). Specifically, in MMAPv1 and FTDC. Although the referenced paths should always be under the dbpath, which has already been resolved at startup, removing these calls to boost's absolute() feels needlessly risky (in a practical sense). All of the possible ways in which getcwd() might fail later during execution indicate some larger problem that the server can't be expected to continue through. There is also the possibility that dynamically linked shared libraries might call getcwd() at any point in time, which would be completely outside the server's control. So, it turns out that the server always needs to know the cwd, and so should fail to start if it can't be determined — ie. this ticket is Works As Designed. Since the cwd is now known to be essential, this very slightly increases the importance of |
| Comment by Scott Hernandez (Inactive) [ 07/Jul/16 ] |
|
So in essence you want the server to start but fail later? Doesn't this "hide" the failure until a potentially worse point, when the server could be active with client requests and then fail due to something which was detectable at startup? What use case is there to allow an invalid working directory when starting the server? |