Thanks — I can help with that. You're asking what "process exited with non-zero exit code -10" means. I don’t yet have enough context to give a precise cause, but I can explain likely meanings and ask a couple quick questions to narrow it down. What the message means (general): • A non-zero exit code means the process terminated with an error (non-success). • The specific code −10 is not a standard POSIX exit code; negative exit codes often indicate the process was terminated by a signal. On many systems, an exit status of −10 corresponds to termination by signal number 10 (SIGUSR1 on Linux/macOS). That implies the process received a signal from the system or another process which caused it to stop. • It can also be produced by the runtime or wrapper that encodes signals as negative exit codes — so it typically points to an external termination (signal) rather than a conventional return() value from your code. Things that commonly cause signal-based termination: • Another process or supervisor sent a signal (for example, for reload, custom handling, or shutdown). • Resource-related kills (less commonly a direct signal 10 — OOM killer uses SIGKILL (9), not 10). • Application code explicitly called raise() or abort() or invoked code that triggers a signal handler. • Misconfiguration in a supervisor (systemd, container runtime, or test harness) that sends a signal on failure or health-check. How I can help next — please provide: 1. Which LiveKit component or executable produced the error? (server, SDK process, client app, a container, etc.) 2. The environment where it occurred: Linux/macOS/Windows, running inside Docker, Kubernetes, or locally? 3. Any surrounding logs (stdout/stderr) from just before the exit — especially lines mentioning signals, stack traces, or "killed". 4. If this happens repeatedly, what triggers it (on startup, when a client joins, during a specific action)? 5. If you control the code: were there any explicit calls to signal handling,

raise()

, or

abort()

? If you share those details I’ll suggest targeted troubleshooting steps — for example, how to check which process sent the signal, how to enable more verbose logs, and how to reproduce safely so we can pinpoint the root cause.