[Feature] Support overriding conf and logs directories in upstream startup scripts
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
Research direction
The issue names four specific shell script files in the hugegraph-dist, hg-pd-dist, and hg-store-dist modules. Start by reading the existing scripts to understand their getopts parsing and path resolution. The change is to add '-c' and '-l' flags, update the USAGE text, and set CONF_OVERRIDE/LOGS_OVERRIDE environment variables. Test by running the modified scripts with the new flags to ensure they override the conf and logs directories correctly.
Written by the indexing model from the issue text.
Description
Feature Description (功能描述)
[Feature] Support overriding conf and logs directories in upstream startup scripts
Description
Currently, HugeGraph startup scripts (start-hugegraph.sh, start-hugegraph-pd.sh, and start-hugegraph-store.sh) resolve configuration and log paths relative to the installation directory ($TOP).
This assumption fails to work in distributed deployments where the installation directory is separate from the runtime CONF and LOGS directories.
This proposal introduces command-line flags (and optional environment variable fallbacks) to allow operators to explicitly override the target paths for CONF and LOGS at startup.
Background
Each startup script ( start-hugegraph.sh, hugegraph-server.sh, start-hugegraph-pd.sh and start-hugegraph-store.sh ) derives its working paths relative to the script location:
BIN=$(abs_path)
TOP="$(cd "$BIN"/../ && pwd)"
CONF="$TOP/conf"
LOGS="$TOP/logs"
This enforces that:
- Config files must reside under
<install-dir>/conf. - Logs must be written to
<install-dir>/logs.
Currently, there is no native mechanism to specify custom runtime directories (such as configuration, logs) outside the unpacked apache-hugegraph-* distribution folder.
Problem
In a distributed cluster deployment, the different roles — Server, Store, and PD may share a common, versioned, immutable installation of the apache-hugegraph-1.7.0 distribution, while their runtime state (configuration, logs) can be managed separately per-node.
Common situations where the current behavior is a blocker:
Multiple roles / instances sharing one install.
Running multiple roles (Server, Store, PD) or distinct instances from a single shared binary distribution, each process requires an isolated configuration workspace and log directory. Forcing all roles to share $TOP/conf and $TOP/logs leads to configuration overwrites and log truncation.
Separation of binaries from configuration.
Operators frequently follow the convention of keeping immutable binaries in one location (e.g. /opt/...) and mutable, node-specific configuration and logs in another (e.g. /etc/... for config and /var/log/... for logs. The current scripts cannot honor this layout.
Read-only / immutable install directory.
In enterprise environments, distribution binaries are frequently installed on read-only filesystems (e.g., shared NFS mounts, OS package directories like /usr/lib/, or immutable container layers). Because HugeGraph scripts attempt to write logs to $TOP/logs and validate write access to $TOP/conf, startup fails on read-only filesystems due to permission errors.
Externally-generated configuration.
Configuration is often generated/templated by an external system into a dedicated writable runtime directory. Today the only way to use it is to copy or symlink files back into <install-dir>/conf, which mutates the installation and defeats the read-only goal.
The net effect: to run HugeGraph roles on a distributed cluster with a read-only install, users have to patch the startup scripts or overlay files into the install tree — both of which are fragile and hard to maintain across upgrades.
Proposed Solution
Add optional command-line flags to each startup script (parsed via the existing getopts blocks) that let the caller override the default directories. When a flag is not supplied, the script falls back to the current behavior, so this change is fully backward compatible.
Proposed flags
| Flag | Overrides | Falls back to |
|---|---|---|
-c <conf_dir> |
Configuration directory | $TOP/conf |
-l <logs_dir> |
Log directory | $TOP/logs |
Flags Overview per script file
start-hugegraph.sh (Server)
| Flag | Meaning | Status |
|---|---|---|
-c |
Override conf directory | New (proposed) |
-l |
Override logs directory | New (proposed) |
-d |
Run as daemon (true/false) |
Existing |
-g |
GC option (e.g. g1) |
Existing |
-j |
Extra user/JVM option | Existing |
-y |
Enable/disable telemetry (true/false) |
Existing |
-m |
Enable/disable monitor | Existing |
-p |
Preload option | Existing |
-s |
Enable/disable security check | Existing |
-t |
Server startup timeout (seconds) | Existing |
hugegraph-server.sh (invoked by start-hugegraph.sh )
| Input | Kind | Meaning | Status |
|---|---|---|---|
CONF_OVERRIDE |
env var | Override conf directory (CONF="${CONF_OVERRIDE:-$TOP/conf}") |
New (proposed) — must be exported by start-hugegraph.sh |
LOGS_OVERRIDE |
env var | Override logs directory (LOGS="${LOGS_OVERRIDE:-$TOP/logs}") |
New (proposed) — must be exported by start-hugegraph.sh |
$1 (positional) |
arg | GREMLIN_SERVER_CONF path |
Existing |
$2 (positional) |
arg | REST_SERVER_CONF path |
Existing |
$3 (positional) |
arg | OPEN_SECURITY_CHECK (true/false) |
Existing |
$4 (positional) |
arg | USER_OPTION |
Existing |
$5 (positional) |
arg | GC_OPTION |
Existing |
$6 (positional) |
arg | OPEN_TELEMETRY (true/false) |
Existing |
start-hugegraph-store.sh (Store)
| Flag | Meaning | Status |
|---|---|---|
-c |
Override conf directory | New (proposed) |
-l |
Override logs directory | New (proposed) |
-d |
Run as daemon (true/false) |
Existing |
-g |
GC option (e.g. g1) |
Existing |
-j |
Extra user/JVM option | Existing |
-y |
Enable/disable telemetry (true/false) |
Existing |
start-hugegraph-pd.sh (PD)
| Flag | Meaning | Status |
|---|---|---|
-c |
Override conf directory | New (proposed) |
-l |
Override logs directory | New (proposed) |
-d |
Run as daemon (true/false) |
Existing |
-g |
GC option (e.g. g1) |
Existing |
-j |
Extra user/JVM option | Existing |
-y |
Enable/disable telemetry (true/false) |
Existing |
The path resolution then becomes:
CONF="${CONF_OVERRIDE:-$TOP/conf}"
LOGS="${LOGS_OVERRIDE:-$TOP/logs}"
Example usage
# Run a role from a read-only install, with writable runtime dirs elsewhere:
./start-hugegraph.sh \
-c /etc/hugegraph/server/conf \
-l /var/log/hugegraph/server
# PD and Store follow the same pattern:
./start-hugegraph-pd.sh -c /etc/hugegraph/pd/conf -l /var/log/hugegraph/pd
./start-hugegraph-store.sh -c /etc/hugegraph/store/conf -l /var/log/hugegraph/store
Backward compatibility: The new behavior is entirely opt-in. With no flags provided, every script behaves exactly as it does today. Existing users and the default distribution layout remain unaffected
Affected Files
- hugegraph-server/hugegraph-dist/src/assembly/static/bin/start-hugegraph.sh
- hugegraph-server/hugegraph-dist/src/assembly/static/bin/hugegraph-server.sh
- hugegraph-pd/hg-pd-dist/src/assembly/static/bin/start-hugegraph-pd.sh
- hugegraph-store/hg-store-dist/src/assembly/static/bin/start-hugegraph-store.sh
- Related util.sh USAGE/help text (where applicable)
Benefits
- Enables running HugeGraph roles (Server, Store, PD) on distributed clusters where binaries and runtime state are intentionally kept in separate locations.
- Allows multiple roles or instances to share a single install while keeping isolated, per-instance conf/logs/plugins.
- Supports read-only / immutable installation directories — a common hardening and reproducibility practice.
- Cleanly integrates with externally-generated configuration without mutating the install tree.
- Backward compatible — no behavior change for existing single-directory deployments.
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 637
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 22
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/hugegraph
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
apache/hugegraph#3231 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
apache/hugegraph#3142 · 7 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
apache/hugegraph#3238 · 2 comments ·
Maintainers usually reply within 1 day
All issues in apache/hugegraph
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
openhab/openhab-core#5847 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
apache/parquet-java#3820 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
beehive-lab/jllm#187 ·