[Bug][v0.3.24]: openviking-server segfaults when started in a child process and hit by health/summary checks. Might relate to stdout/stderr redirection.

[xiaobin83]

Bug Description

OpenViking sever segfaults when execute the scripts attached.

First execute spawn-server.sh below to start the server,

#!/bin/bash
# 以子进程方式启动 openviking-server，模拟 app 的启动行为
# 用法：
#   bash scripts/spawn-server.sh
#   . scripts/spawn-server.sh  (保持变量在当前 shell)

set -m  # 启用 job control，后台进程获得独立进程组

VENV_PYTHON="/Users/xxxx/Library/Application Support/com.openviking.desktop/python/bin/python3"
VENV_ROOT=$(dirname "$(dirname "$VENV_PYTHON")")
VENV_BIN="$VENV_ROOT/bin"
SERVER_CMD="$VENV_BIN/openviking-server"
CONFIG="$HOME/.openviking/ov.conf"
PORT=1934

export VIRTUAL_ENV="$VENV_ROOT"
export PATH="$VENV_BIN:$PATH"

"$SERVER_CMD" \
  --host 127.0.0.1 \
  --port $PORT \
  --config "$CONFIG" &

Then execute health-check.sh below,

#!/bin/bash

BASE_URL="http://127.0.0.1:1934"
AUTH="Authorization: Bearer test"
ACCOUNT="X-OpenViking-Account: default"
USER="X-OpenViking-User: default"

echo "=== Health Check ==="
curl -v -X GET \
  -H "$AUTH" \
  -H "$ACCOUNT" \
  -H "$USER" \
  "$BASE_URL/health"

echo ""
echo "=== Dashboard Summary ==="
curl -v -X GET \
  -H "$AUTH" \
  -H "$ACCOUNT" \
  -H "$USER" \
  "$BASE_URL/api/v1/console/dashboard/summary"

And the server segfaults.

---

When I change the command of start to redirect stdout/stderr to a file. it wont crash.

"$SERVER_CMD" \
  --host 127.0.0.1 \
  --port $PORT \
  --config "$CONFIG" > server.log 2>&1 &

---

ov.conf

{
  "server": {
    "host": "127.0.0.1",
    "port": 1934,
    "root_api_key": "test",
    "cors_origins": [
      "*"
    ]
  },
  "storage": {
    "workspace": "/Users/xxxx/.openviking/data",
    "vectordb": {
      "name": "context",
      "backend": "local"
    },
    "agfs": {
      "backend": "local"
    }
  },
  "embedding": {
    "max_concurrent": 10,
    "max_retries": 3,
    "dense": {
      "provider": "local",
      "model": "bge-small-zh-v1.5-f16",
      "model_path": "/Users/xxxx/Workspace/openviking/openviking-desktop/src-tauri/Resources/models/bge-small-zh-v1.5-f16.gguf"
    },
    "circuit_breaker": {
      "failure_threshold": 5,
      "reset_timeout": 60,
      "max_reset_timeout": 600
    }
  },
  "vlm": {
    "max_retries": 3,
    "max_concurrent": 100,
    "timeout": 60,
    "thinking": false,
    "stream": false,
    "provider": "deepseek",
    "api_key": "sk-vo50",
    "model": "deepseek-v4-flash",
    "api_base": "https://api.deepseek.com",
    "temperature": 0.1
  },
  "encryption": {
    "enabled": false
  },
  "log": {
    "level": "INFO",
    "format": "%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    "output": "stdout",
    "rotation": true,
    "rotation_days": 3,
    "rotation_interval": "midnight"
  },
  "feishu": {
    "domain": "https://open.feishu.cn",
    "max_rows_per_sheet": 1000,
    "max_records_per_table": 1000
  }
}

Steps to Reproduce

Check the description.

Expected Behavior

After the monitor starts a openviking-server as a child process, the monitor should be able to watch the status of the server.

Actual Behavior

The server crashes when the monitor tries to access health and summary.

Minimal Reproducible Example

Error Logs

health-check log

=== Health Check ===
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 127.0.0.1:1934...
* Connected to 127.0.0.1 (127.0.0.1) port 1934
> GET /health HTTP/1.1
> Host: 127.0.0.1:1934
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer test
> X-OpenViking-Account: default
> X-OpenViking-User: default
> 
* Request completely sent off
2026-06-07 12:21:16,059 - uvicorn.access - INFO - 127.0.0.1:52994 - "GET /health HTTP/1.1" 200
< HTTP/1.1 200 OK
< date: Sun, 07 Jun 2026 04:21:15 GMT
< server: uvicorn
< content-length: 149
< content-type: application/json
< x-process-time: 0.007102667004801333
< 
* Connection #0 to host 127.0.0.1 left intact
{"status":"ok","healthy":true,"version":"0.3.24","auth_mode":"api_key","account_id":"default","user_id":"default","agent_id":"default","role":"root"}
=== Dashboard Summary ===
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 127.0.0.1:1934...
* Connected to 127.0.0.1 (127.0.0.1) port 1934
> GET /api/v1/console/dashboard/summary HTTP/1.1
> Host: 127.0.0.1:1934
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer test
> X-OpenViking-Account: default
> X-OpenViking-User: default
> 
* Request completely sent off
* Empty reply from server
* Closing connection
curl: (52) Empty reply from server

OpenViking Version

0.3.24

Python Version

3.13.13

Operating System

macOS

Model Backend

None

Additional Context

No response

[qin-ctx]

Thanks for reporting this!

We traced the current code path and /health is much lighter than /api/v1/console/dashboard/summary. The health endpoint only assembles basic status and identity information (openviking/server/routers/system.py). The dashboard summary endpoint goes through openviking/server/routers/console.py -> openviking/observability/usage_audit/api_service.py -> ContextInventoryProvider in openviking/observability/usage_audit/inventory.py.

The suspicious part is the dashboard inventory count: it calls fs.stat() for viking://resources, user skills, and user memories. For directory stats, VikingFS.stat() also performs a VectorDB count() with a path-scope filter (openviking/storage/viking_fs.py), and the local VectorDB backend eventually enters the native C++ index engine count/search path (openviking/storage/vectordb/index/local_index.py, src/index/detail/index_manager_impl.cpp).

Since your workaround changes stdout/stderr handling, we need a little more data to distinguish between a native VectorDB crash and a process/stdout signal issue.

Could you provide the following?

1. The server exit code after the crash:

   "$SERVER_CMD" \
     --host 127.0.0.1 \
     --port $PORT \
     --config "$CONFIG" &
   SERVER_PID=$!
   echo "server pid: $SERVER_PID"
   
   # Run health-check.sh in another terminal, or below this block.
   wait "$SERVER_PID"
   echo "server exit code: $?"

2. The macOS crash report from:

   ls -lt ~/Library/Logs/DiagnosticReports | head

   The file may be named openviking-server_*.crash, python3_*.crash, or similar.

3. If possible, an lldb backtrace:

   lldb -- "$SERVER_CMD" --host 127.0.0.1 --port 1934 --config "$CONFIG"

   In lldb:

   run
   

   After it crashes:

   thread backtrace all
   

4. Please also try the directory stat endpoints individually:

   curl -v -H "$AUTH" -H "$ACCOUNT" -H "$USER" \
     "$BASE_URL/api/v1/fs/stat?uri=viking://resources"
   
   curl -v -H "$AUTH" -H "$ACCOUNT" -H "$USER" \
     "$BASE_URL/api/v1/fs/stat?uri=viking://user/default/skills"
   
   curl -v -H "$AUTH" -H "$ACCOUNT" -H "$USER" \
     "$BASE_URL/api/v1/fs/stat?uri=viking://user/default/memories"

If one of these fs/stat calls also crashes the server, that would narrow the issue to the directory stat -> VectorDB count path. If only the dashboard endpoint crashes, we will focus on the concurrent inventory aggregation path.

If you're interested in contributing a fix, we'd be happy to provide guidance once we have the crash report or backtrace.