https://livekit.io logo
Join Slack
Powered by
I get a lot of errors like this: ```process exited...
# ask-ai
t
I get a lot of errors like this:
Copy code
process exited with non-zero exit code -10
What's code "-10" ?
t
Thanks for reaching out, Pierrick. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m responding to your question about the repeated message: process exited with non-zero exit code -10 I don’t have a specific mapping for “-10” from LiveKit internals here, so I need a little more context to give a precise answer. Common possibilities and next steps: What “-10” often means • Many operating systems and runtimes use negative exit codes to indicate a process was terminated by a signal. For example: ◦ On Unix-like systems, an exit of -N can correspond to termination by signal N (e.g., -6 → SIGABRT). In that interpretation, -10 would mean the process was terminated by signal 10 (SIGUSR1 on many Unix systems). ◦ Some runtimes or wrappers use negative values as internal error codes (not signals), so -10 could be an application-defined error. What I need from you to narrow it down • Which component/process is printing this message? (e.g., LiveKit server, a worker, a client SDK, a custom service) • What OS and environment is the process running on? (Linux distro, macOS, Docker, Kubernetes) • Anything notable in nearby logs? Share a few lines before/after the exit message. • Does the process restart automatically? Is there any pattern (after X minutes, when load is high, on specific actions)? • If possible, the command or binary name that’s exiting. Immediate checks you can run • Inspect system logs (e.g., 
dmesg
or 
journalctl -u <service>
on Linux) for OOM killer or other kernel signals around the same timestamp. • Check the process supervisor logs (systemd, Docker container logs, k8s pod events) for termination reason. • If you can reproduce, run the process under a debugger or wrap it to capture core dumps (
ulimit -c unlimited
) and inspect with gdb if a core appears. • Look for application-level logs that might show an explicit call to exit with -10. If you share the process name, environment, and a few surrounding log lines/timestamps, I’ll interpret the evidence and suggest targeted next steps (e.g., check for SIGUSR1 handling, OOM, or a known internal error code), and provide commands/examples to gather diagnostic data.
t
I'm also seeing a lot of
Copy code
sending SIGUSR1 signal to process
logs
t
Thanks — that extra detail is very helpful. I’m responding to your report about repeated process exited with non-zero exit code -10 and the related sending SIGUSR1 signal to process logs. What exit code -10 means here • An exit code of -10 is the same as the process being terminated by signal 10. Signal 10 is SIGUSR1 on most Unix-like systems, so the process is being killed with SIGUSR1 rather than exiting normally. • In short: the process isn’t crashing on its own; something is explicitly sending SIGUSR1 to it. Why SIGUSR1 might be sent • Health checks or supervisors: Some process managers or custom supervisors use SIGUSR1 to trigger graceful diagnostics, log rotation, or controlled shutdown/restart. • Internal tooling: A monitoring or orchestration tool (e.g., your deploy scripts, a sidecar, or a supervisor) might be using SIGUSR1 to ask the process to do something or to restart it. • Self-healing automation: In Kubernetes or container environments, liveness probes, crash handlers, or controllers might send signals when they detect a problem. • Debugging/maintenance: Someone or something in your environment might be manually sending SIGUSR1 for debugging or to trigger special behavior if the process supports it. What to check next (targeted diagnostics) 1. Identify the sender ◦ Search your environment for any scripts or supervisors that send SIGUSR1 (grep for 
kill -USR1
, 
pkill -USR1
, 
docker kill --signal=SIGUSR1
, etc.). ◦ Check orchestration events: in Kubernetes, run 
kubectl describe pod <pod>
and 
kubectl get events
for any termination or restart events near the timestamps. 1. Correlate timestamps and surrounding logs ◦ Share a few lines of logs before and after both the “sending SIGUSR1” line and the “exited -10” line. The surrounding messages often show who issued the signal or why. ◦ Check system logs: 
journalctl -u <service>
or 
journalctl --since "<time>"
and 
dmesg
for kernel messages (OOM killer, cgroup actions). 1. Check process behavior on SIGUSR1 ◦ Does the binary have special handling for SIGUSR1? If you control the code, search for signal handlers that trap SIGUSR1 and call exit or cleanup. If it’s an upstream binary, consult its docs or search the code for SIGUSR1 handlers. ◦ If unknown, run the process in a controlled environment and send SIGUSR1 manually (
kill -USR1 <pid>
) to see what it does while watching logs. 1. Supervisor / container runtime checks ◦ If managed by systemd: run 
systemctl status <service>
and check the unit file for any ExecStop/ExecReload handlers that use SIGUSR1. ◦ If Docker: 
docker ps
, then 
docker logs <container>
and 
docker inspect <container>
to see restart policies or health-check-related behavior. ◦ If Kubernetes: check pod spec for liveness/readiness probes, preStop hooks, or lifecycle hooks that may use signals. 1. If you suspect automated restarts or rotation ◦ Look for log-rotation tools (logrotate with 
postrotate
scripts), or custom deploy hooks that may use SIGUSR1. ◦ Check any monitoring/observability agents that can restart or signal processes when they detect issues. If you can share any of the following, I can give concrete next steps: • The process/binary name that’s receiving SIGUSR1 (e.g., LiveKit server, worker, a custom app). • A few lines of logs (timestamps) before and after both the “sending SIGUSR1” and the “exited -10” messages. • Where this is running (Linux distro, Docker, Kubernetes, systemd). • Whether the process has a restart supervisor and whether it restarts automatically. I can then help you: • Identify the sender of SIGUSR1, • Determine whether SIGUSR1 is being used to trigger a restart or diagnostics, • Suggest fixes (adjusting supervisors, altering signal handling, or preventing unwanted signals). If you prefer, paste the surrounding log snippet and the process name and I’ll analyze it and provide exact commands to run.
t
Sent here: /app/.venv/lib/python3.13/site-packages/livekit/agents/ipc/supervised_proc.py
t
I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!
t
Why would Livekit send such a SIGUSR1 Signal?
2 Views
Open in Slack
PreviousNext
Powered by