custody and custody-probe assign different meanings to CUSTODY_PROC_DIR

[wearhere]

Problem

custody treats this environment variable as an override for the root storage directory. custody-probe, on the other hand, treats it as an override for the process statefile directory, which is normally a subdirectory /services of the root storage directory. This prevents custody and probe-instrumented processes (i.e. supervisor) from using the same value for this environment variable; if they do, probes will write statefiles a directory above where custody expects to read them.

Workarounds

If you are on OS X, you probably don't need to set CUSTODY_PROC_DIR at all, since you will find custody's default storage directory writable—the variable was originally added to support Linux.

If do wish to use the variable and also care about keeping the probes functional i.e. you wish to use plugins like https://github.com/mixmaxhq/custody-plugin-start-debugger, then a workaround is to set environment variables like this:

1. Before launching custody: export CUSTODY_PROC_DIR="/some/base/path"
2. Before launching supervisor: export CUSTODY_PROC_DIR="/some/base/path/services"

If all you care about is preventing Supervisor from writing files into /usr/local/var (the original motivation for introducing the variable), then you can set CUSTODY_PROC_DIR to any writable directory.

Fixes

A more permanent fix would be to change how custody and/or the probes interpret the variable, and/or introduce new variables. custody-probe's interpretation of the existing variable is probably more accurate than custody's, since the default value here that the probe replaces with the variable is the process directory.

That said, it'd probably be more useful to let users override the root storage directory to prevent custody from writing other files like the settings file into /usr/local/var, so I would be in favor of deprecating CUSTODY_PROC_DIR in favor of a new variable like CUSTODY_STORAGE_DIR that would be analogous to /usr/local/var/custody.