flipped-aurora/gin-vue-admin · error

MCP 独立进程已退出,请查看日志: %s

Error message

MCP 独立进程已退出,请查看日志: %s

What it means

waitForManagedProcess detects that the spawned standalone MCP process exited (its recorded PID no longer exists) while still unreachable, before the start deadline expired. This is an early-exit fast-fail so developers don't wait the full timeout; the log path is included for diagnosis.

Source

Thrown at server/mcp/standalone_manager.go:287

func waitForManagedProcess(ctx context.Context, meta *managedProcessMeta) (ManagedStandaloneStatus, error) {
	deadline := time.NewTimer(mcpStartWaitTimeout)
	ticker := time.NewTicker(300 * time.Millisecond)
	defer deadline.Stop()
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return GetManagedStandaloneStatus(context.Background()), ctx.Err()
		case <-deadline.C:
			return GetManagedStandaloneStatus(context.Background()), fmt.Errorf("等待 MCP 独立服务启动超时,请查看日志: %s", meta.LogPath)
		case <-ticker.C:
			current := GetManagedStandaloneStatus(context.Background())
			if current.Reachable {
				return current, nil
			}
			if meta.PID > 0 && !processExists(meta.PID) {
				return current, fmt.Errorf("MCP 独立进程已退出,请查看日志: %s", meta.LogPath)
			}
		}
	}
}

func resolveManagedStartCommand() (string, []string, string, string, error) {
	serverRoot := resolveMCPServerRoot()
	if serverRoot == "" {
		return "", nil, "", "", errors.New("未找到 server 根目录,无法启动 MCP 独立服务")
	}

	configPath, err := resolveMCPConfigPath(serverRoot)
	if err != nil {
		return "", nil, "", "", err
	}

	if explicit := strings.TrimSpace(os.Getenv("GVA_MCP_BIN")); explicit != "" {
		if !fileExists(explicit) {

View on GitHub (pinned to 3136500ef3)

Solutions

  1. Read the log file at meta.LogPath — the crash reason (panic, connection refused, port in use) is captured there since stdout/stderr go to the log.
  2. Fix the root cause: free the port, correct the config, restore env/dependencies.
  3. Re-run StartManagedStandalone after fixing; the manager will spawn a fresh process.
  4. If OOM is suspected, check dmesg/journal and increase memory limits.

Example fix

// before (guessing)
StartManagedStandalone(ctx)
// after (diagnose first)
cat /path/to/mcp.log   # path shown in the error
ss -ltnp | grep <port> # confirm no port conflict
GVA_MCP_BIN=$(pwd)/mcp StartManagedStandalone(ctx)
Defensive patterns

Strategy: try-catch

Validate before calling

// after a crash, inspect the log before restarting
if logs, err := os.ReadFile(meta.LogPath); err == nil {
    if strings.Contains(string(logs), "panic") {
        return fmt.Errorf("mcp binary panics on boot; fix before restart")
    }
}

Try / catch

status, err := StartManagedStandalone(ctx)
if err != nil && strings.Contains(err.Error(), "已退出") {
    tail, _ := os.ReadFile(meta.LogPath)
    log.Printf("standalone exited; log tail: %s", tail)
    return err // do not hot-retry a crashing binary
}

Prevention

When it happens

Trigger: Process starts then crashes during initialization: panic in config parsing, failed DB/Redis connection with os.Exit, missing env vars, port already in use causing immediate exit — detected when processExists(meta.PID) returns false on a ticker tick.

Common situations: Config file deleted/renamed after spawn; port conflict with another service; incompatible config schema after upgrade; OOM-killer terminating the process; missing runtime dependencies (CGO libs).

Related errors


AI-assisted analysis of flipped-aurora/gin-vue-admin@3136500ef3 (2026-08-31). Data as JSON: /api/errors/67311c7e8f028206. Report an issue: GitHub.