Skip to main content

Start · Stop · Restart

There are two places where you control the data lake power. The container itself is managed on the host; a single service inside the container is managed pd. Decide which one you need first.

TaskLocationCommand
Power the entire Platform on and offHostup.sh · down.sh · restart.sh
Rebuild the data lake only after changing configuration or passwordHostrestart-datalake.sh
Restart a single app (server · batch · warehouse)Hostrestart-server.sh · restart-batch.sh · restart-warehouse.sh · restart-one.sh <서비스>
Restart a single service inside the data lake (CEP · workflow …)Inside containerpd restart <서비스>
Check statusHost / Inside containerstatus.sh / pd status

Host commands​

cd /opt/kopens/plantpulse-platform-docker/bin

./up.sh                 # 기동 — 준비될 때까지 기다린다. 종료 코드 0 = 쓸 수 있다
./down.sh               # 정지 — 컨테이너 · 볼륨은 남는다
./restart.sh            # 전체 재시작 — graceful drain → 재기동 → 준비 대기. 인자를 받지 않는다
./restart-datalake.sh   # 데이터레이크만 — drain → 재생성 → 준비 대기 → 의존 앱 판정
./status.sh             # 컨테이너 · 헬스 · 볼륨 요약. 0 = 정상 / 2 = 비정상
CommandExit code 0 meansNote
up.sh«is usable» — not a success signal. Re-checks until readiness probe passes (default 900 seconds, 15-second intervals)If PP_WAIT=0, does not wait, and 0 then does not indicate readiness
restart.shReady after restartAll six apps · proxy · certificate container included. Use when you change a value that affects apps too, like language or timezone
restart-datalake.shData lake is healthy again, and its dependent apps tooA single container but a stack event — all apps hold connections to it, so after it finishes, it evaluates all apps and restarts only those that couldn't come back on their own. Takes as long as a full boot
status.shNormalVolumes · conf are reported only; not included in the exit code
If you changed a value, use restart-datalake.sh not docker restart

Sidecar and node file values enter the container as environment variables when compose rebuilds it. docker restart plantpulse-datalake only powers back on with the same environment variables, so new values do not take effect.

Startup sequence​

Between containers​

plantpulse-certs (TLS material) → plantpulse-datalake → six apps · proxy. Apps start only after the data lake becomes healthy. The data lake startup grace period is 900 seconds, and the first boot can take that long due to Cassandra schema creation.

Inside the data lake​

When the container starts, pd start automatically helps.

  1. If core ports (6379 · 5432 · 9042) are already open, reject as «already running».
  2. Verify all 15 required secrets are present (workers: +1). If missing, list all names and exit 3.
  3. Check TLS material (/var/security/plantpulse).
  4. Configuration render — render all templates to actual files under PP_HOME. Every time, without exception.
  5. Start in storage → analytics → messaging → timeseries → cep → workflow → data-gateway → admin-api order and wait for each to reach health check UP.

The last line is the result.

datalake started: 8 service(s) ready. Logs: pd logs                                  # exit 0
datalake started with 1 service(s) not ready (7 ready). Check: pd status              # exit 6

Shutdown sequence​

On the host, down.sh · restart.sh bring down apps first and drain the data lake — inside the container, pd stop brings down services in reverse order (admin-api → … → storage), each proving it «has stopped» (30-second wait → SIGTERM 15 seconds → SIGKILL 10 seconds). The container stop grace period (stop_grace_period) is 180 seconds.

Do not stop storage alone and leave the rest

All the services above depend on storage. If you are going to stop them, use pd stop which stops everything in reverse order, and if you are doing that, the host's down.sh which stops the container itself is better. If you run pd stop the whole thing «just to quiet it down», the container HEALTHCHECK will become unhealthy in a few minutes and the host-side monitoring will respond.

Single service — pd​

docker exec plantpulse-datalake pd status            # 어느 것이 STOPPED 인가
docker exec plantpulse-datalake pd logs --lines 100 cep
docker exec plantpulse-datalake pd restart cep       # stop → 정지 증명 → 5초 → start
ServiceRestarting it causes
storageAll dependents lose their connection. Prefer the host's restart-datalake.sh to restart the whole stack
analyticsAll running SQL · Spark jobs stop. If an archive job is running, wait for it to finish
messagingMessage reception stops for a few seconds. Consumers (server · CEP · batch) reconnect automatically
timeseries · cep · workflow · data-gateway · admin-apiThat service only. Apps reconnect automatically

pd restart proves stop first. If stop fails (exit 7), it stops there — then try pd kill --dry-run → pd kill → pd status → pd start.

Check status one line at a time​

./status.sh                                            # 호스트: 0 정상 / 2 비정상
docker ps --format 'table {{.Names}}\t{{.Status}}'      # 컨테이너와 (healthy)
docker exec plantpulse-datalake pd status              # 서비스 포트 표
curl -kfsS https://<server-ip>:4950/api/health | jq .status   # 콘솔 헬스 API
«Up but dead» — memory OOM

Since PID 1 inside the container is systemd, only the Java process gets cgroup OOM-killed and docker ps continued to show Up (healthy) until it was too late to become unhealthy. If pd status are all STOPPED but the container is still alive, suspect this first.

dmesg -T | grep -i "memory cgroup"                                   # 호스트
docker inspect plantpulse-datalake --format '{{.State.OOMKilled}}'

How to raise the limit is in Changing configuration — memory.

Auto-start​

The container has restart: always, so when the host reboots, the Docker daemon starts it automatically. No separate systemd unit is needed. However, a stack you intentionally stopped with down.sh stays down after reboot — bring it up with up.sh.