[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:
Related
related to SERVER-24914 Cannot start mongod from cwd > 1000 b... Closed
related to SERVER-24915 getcwd() failure should report errno Closed
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 SERVER-24914 and SERVER-24915.

getcwd() is called from setupCwd(), which sets serverGlobalParams.cwd. This variable is only used in two places:

  1. Resolving a relative dbpath (when --fork is used)
  2. Resolving the logpath (in all cases)

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:

  1. logpath is only resolved if it is relative (same as is done for dbpath)
  2. setupCwd()/getcwd() is only called if:
    • the dbpath is relative (does not start with /) and {--fork}} is used, and/or
    • the logpath is relative (does not start with /)

There are a few ways of doing this, but I think a better fix would be:

  1. logpath is only resolved if it is relative (same as is done for dbpath)
  2. don't assert if getcwd() fails
    • log a warning instead
    • leave serverGlobalParams.cwd as the empty string
    • then access serverGlobalParams.cwd via a wrapper function which returns it or fasserts if it's empty


 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 SERVER-24915.

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?

Generated at Thu Feb 08 04:07:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.