How long does livekit waits to kill the process on participant_disconnected?

Thanks for reaching out, Mario. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

• The server/host process shutting down after a room becomes empty.

You're asking about the server/host process shutting down after a room becomes empty. LiveKit does not kill the server/host process when a room becomes empty. Instead, individual rooms are closed after an

empty_timeout

period when no participants remain. The default

empty_timeout

is 20 seconds (this is configurable when creating rooms or in self-hosted settings). The server process itself continues running and will accept new rooms or connections unless you explicitly stop it. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Managing rooms | LiveKit docs | Job lifecycle | LiveKit docs

So, I have this code:

self._call_sip_ctx.room.on(
            "participant_disconnected",
            lambda: asyncio.create_task(self._shutdown()),
        )

If _shutdown takes longer than 5 seconds to execute, what happens? Does livekit shutds down the job?

You're triggering

_shutdown

with

asyncio.create_task()

on

participant_disconnected

. That task runs independently — LiveKit/Agents does not kill it after 5 seconds. What happens: • The task will continue running until it completes or the agent process is terminated. • The Agents framework waits for shutdown hooks but will forcefully terminate the process only after the configured

shutdown_process_timeout

(default 60 seconds). • If your

_shutdown

finishes within

shutdown_process_timeout

, it will complete normally. If it exceeds that timeout, the process may be forcefully terminated. If you want, I can show how to: • increase

shutdown_process_timeout

, or • make

_shutdown

async with a cancellable pattern and a short internal timeout. Sources: Job lifecycle | LiveKit docs

When is shutdown_process_timeout used? Based on which event?

You're asking when

shutdown_process_timeout

is applied. • It's used when the Agents framework initiates a graceful shutdown of the agent process — for example when all participants have left a room and the agent begins its shutdown sequence, or when the server/process is explicitly stopped. • At that point the framework waits for registered shutdown hooks (like your

_shutdown

task) to finish. • The

shutdown_process_timeout

value (default 60 seconds) is the maximum time the framework will wait for those hooks; if hooks haven't completed by then, the process may be forcefully terminated. Would you like the exact place to configure

shutdown_process_timeout

or an example of a cancellable

_shutdown

pattern?

ah, ok. that's my root cause AI 😛

Glad that helped — nice catch! 😄 If you'd like, I can: • show how to increase

shutdown_process_timeout

in your agent/server config, or • provide a cancellable async

_shutdown

pattern with a short internal timeout to avoid hitting the process-level timeout. Which would you prefer?

Well, I still don't have an answer. Turns out the server is ending with

process exiting

, so it isn't necessarily a timeout

Thanks — you mentioned the server is ending with a "process exiting" message, so I'll focus on diagnosing why the process itself is terminating (not the room empty timeout). Quick checks to narrow this down — please tell me any of the following and paste relevant log lines around the "process exiting" message: • Are you running the agent/process in Docker, Kubernetes, systemd, or directly on a host? • Any orchestration events at that time (deploy/update, liveness/readiness probe failures, OOM/killed by kernel)? • Do your logs show signals like

SIGTERM

or

SIGINT

, or messages containing

draining

,

shutdown

,

disconnect

, or

session ended

? • Is your code calling

process.exit()

,

sys.exit()

,

room.disconnect()

,

session.shutdown()

, or similar after

participant_disconnected

? • Do you have agent server options set for

drain_timeout

or

shutdown_process_timeout

(values)? What to look for in logs (share lines if possible): • Receipt of `SIGTERM`/`SIGINT` or "draining" — indicates external shutdown signal or orchestrator. • Messages about

session ended

or

all participants left

followed by explicit exit calls — indicates application-level exit. • Container runtime messages like

Killed

or OOM — indicates resource kills. • Any stack trace or explicit

process exiting

caller name. What I can do once you share logs/config: • Point to whether the exit is from agent shutdown hooks (and whether

shutdown_process_timeout

would apply). • Identify if an orchestration/system signal likely triggered the exit. • Suggest the exact config change or code pattern to avoid premature exit (increase timeouts, make

_shutdown

cancellable, or prevent process.exit calls). Which logs/config can you share first? Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Job lifecycle | LiveKit docs | Agent server options | LiveKit docs

Yeah, in this case, all participants left the call.

You're saying all participants left — that will trigger the Agents framework to end the agent session and start a graceful shutdown, which is why you see the process exit. Key points: • When the room becomes empty the agent session ends and the framework begins shutdown hooks (this is the event causing the process to exit). •

shutdown_process_timeout

(default 60s) is how long the framework waits for those hooks (like your

_shutdown

) before forcefully terminating the process. • The room empty/agent-session behavior is automatic; the server process itself (the LiveKit server) isn't killed by this — it's the agent/session process lifecycle that ends. You can change behavior by adjusting agent server options: • Increase

shutdown_process_timeout

to allow longer shutdown hooks. • Disable/alter automatic session shutdown (keep-alive or auto-shutdown settings) if you want the agent to remain after participants leave. If you want, paste your agent config or the log lines around "process exiting" and I’ll point to the exact option to change and an example config snippet.