Pivotal Knowledge Base

Follow

Members started with GFSH doesn't pick up gemfire.properties

Applies to

GemFire 7 and later

Purpose

To describe several solutions to get members to use the needed gemfire.properties when starting members using GFSH.

Issue

When using gfsh to start a locator or server they don't pick up the expected gemfire.properties.

Solution

By default, GFSH will start the locator or server in a subdirectory of the same name as the process. Ex: "start locator --name=locator1" will use ./locator1 as the current working dir for that process. 

1) if the subdirectory does not exist use:

gfsh>start locator --name=locator1 --properties-file=<path to file>

2) if the subdir does exist (either you created or GFSH did previously) copy the gemfire.properties to that subdirectory if you want to avoid specifying it every time:

gfsh>start locator --name=locator1

Note, the options are relative to "Gfsh's" working directory, not the GemFire process.  Also note, the "name" (as specified with "start [locator|server] --name=X") is the name of the GemFire member, not the actual JVM process.

GFSH will pass the "location" (file system path) to the forked GemFire process by way of a (GemFire) System property as described in the User's Guide.  The GemFire process will look for gemfire.properties and cache.xml, etc relative to it's own working directory unless an absolute path is given.

GemFire does use "default" locations when looking for certain configuration files: working dir, user home dir, classpath.  Though these default locations can be used, it is recommended you specify the location of configuration files explicitly to avoid unexpected things happen when you forget that you left a configuration file (.properties or cache.xml) in you home directory, for instance. 

Comments

Powered by Zendesk