When --fork (or the config file equivalent) is used, the server will chdir to /. Presumably this is by design, and to avoid any later problems from the server having an unrelated cwd (eg. if started from somewhere inside /home, then without this /home cannot be unmounted without stopping the server, even if the dbpath and all other files used by the server are elsewhere).

However, this means that if relative paths are specified for various config options (eg. config file, dbpath, pidfilepath), then even though they are correctly handled, it is impossible to know later what the cwd was when they were initially resolved. This can make diagnosis more difficult than it should be, because diagnostic tools such as mdiag.sh are unable to programmatically locate these files.

Thus, it would good if there was a way to be able to locate such files, even when they have been specified relatively and --fork is in use. Ideally this would be done in a way that doesn't require communicating with the server.

Possibilities include:

• Log the cwd just before chdiring to /. Con: these logs may no longer be available.
• Remember the previous cwd, and expose via getCmdLineOpts (or similar). Con: tools like mdiag are sometimes unable to directly query the database, since that would require credentials (this isn't impossible, just difficult).
• Resolve the relative paths so that they are absolute (eg. boost::filesystem::absolute) before storing in global state. Con: as above; argv cannot usually be adjusted this way because it would need to grow.
• Completely forbid relative paths. Con: may break existing user deployments, may break tests/tools/etc which legitimately use relative paths (eg. for cleanup purposes).