How do I change which port the agent is listening ...
# ask-ai
s
How do I change which port the agent is listening to
t
Thanks for reaching out, Ajay. 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 changing which port the agent listens on. The agent itself does not listen on an incoming port. It makes outbound WebSocket connections to your LiveKit server using the LiveKit URL you provide (typically
wss://
on port 443 or
ws://
on port 80). That means there’s no agent-side port configuration to change for incoming connections. If you need to change ports, do so on the LiveKit server side. Relevant LiveKit server ports are: • Port 7880 (or 443 if behind a proxy) — client connections • Port 7881 — internal service communication • Port 7882/UDP — media / TURN server From the agent side, ensure the
LIVEKIT_URL
environment variable points to the correct LiveKit endpoint (including the correct host and port if you’re using a non-standard port). If you tell me: • the
LIVEKIT_URL
you’re currently using, and • whether your LiveKit server is behind a proxy or using custom ports, I can help you form the exact
LIVEKIT_URL
value and verify connectivity steps to confirm the agent can reach the server. Sources: Self-hosted deployments | LiveKit Documentation
s
I have deployed an agent as service in ec2 it is working but when I deployed a different agent on the same ec2 it is saying something else is using the port error
t
Thanks — I’m sorry you’re running into that port-in-use error. You mentioned the first agent runs fine but a second agent on the same EC2 fails with “something else is using the port.” I’ll help you diagnose and resolve it. What’s happening • The agent itself does not accept public inbound connections; it opens outbound WebSocket connections to the LiveKit server. • However, agents may run a local HTTP service (by default a health-check endpoint on
0.0.0.0:8081
) or other local servers. If two agent processes try to bind the same local port, the second will fail with a port-in-use error. Immediate steps to find the conflict 1. Check which processes are listening on host ports:
Copy code
sudo netstat -tulnp | grep LISTEN
or
Copy code
sudo ss -tulnp | grep LISTEN
Look for port
8081
(or whatever port the error mentions) and note the PID and process name. 1. Inspect the failing agent’s logs or the exact error message — which port is it reporting as in use? How to fix it • Change the agent’s local port: ◦ If the conflict is the health-check endpoint (default
8081
), configure the second agent to use a different port for its health endpoint. • Run agents in isolation: ◦ Start each agent in separate Docker containers (each container can listen on the same internal port while mapping to distinct host ports), or ◦ Use separate systemd service units with different environment variables/ports. • If the agents must run as host processes, ensure each has unique ports for any local HTTP/RPC/metrics endpoints. What I need from you to give exact commands/configuration • The exact error message text you see when the second agent fails. • Output of one of these commands from the EC2 host after the failure: ◦
sudo netstat -tulnp | grep LISTEN
(or
sudo ss -tulnp | grep LISTEN
) • How you deployed each agent (systemd service, Docker container, plain process), and whether you used any custom environment variables (especially
HEALTH_PORT
or similar) or config files. If you share the error message and the `netstat`/`ss` output, I’ll point out which process is blocking the port and show the exact change you should make to the second agent (example systemd unit or Docker run flag) to resolve it. Sources: Self-hosted deployments | LiveKit Documentation
s
I have deployed it as systemd service file Also I don't want to stop other agent
t
Thanks — I can help you run both agents concurrently without stopping the first one. From what you described, the conflict is likely a local port (commonly the health-check endpoint on 0.0.0.0:8081) that both agent processes try to bind. Since you’re using systemd, the easiest fix is to give the second agent a different local port (or run it in an isolated network namespace/container). I’ll guide you through the systemd route. Quick questions so I can give the exact systemd change: • What exact error message does the second agent show? Please paste the full line(s). • Which port does the error mention (if any)? If you’re not sure, run one of these and paste the relevant lines: ◦ sudo ss -tulnp | grep LISTEN ◦ sudo netstat -tulnp | grep LISTEN • Please paste the systemd service file for the second agent (the failing one). If you prefer, paste both service files so I can compare. What I’ll do once you share that: • Identify which port is in use and which process holds it. • Show the minimal edit to the second agent’s systemd unit (usually an environment variable or ExecStart argument) to change the health/HTTP port. • Provide the exact systemd commands to reload and start the updated service (so you can keep the current agent running). If you’d like a quick example while you gather those details — here’s a template showing the typical change (replace
MY_AGENT
and variable names with your actual names): 1. Edit the service to add or modify an environment variable for the health port:
Copy code
[Unit]
Description=My LiveKit Agent 2
After=network.target

[Service]
Type=simple
Environment="HEALTH_PORT=8082"
ExecStart=/usr/bin/my-agent --health-port ${HEALTH_PORT}
Restart=on-failure

[Install]
WantedBy=multi-user.target
1. Then reload and restart only the updated service:
Copy code
sudo systemctl daemon-reload
sudo systemctl restart my-agent-2.service
Share the error,
ss/netstat
output, and your service file and I’ll give the exact edits and commands tailored to your setup.
s
i have created a service file for both the agent and the first agent is running crtly but the second one throws error saying port already in use now how do i change the port for my second agent i want both the agent to run on it simultaneously
t
Thanks — I’ll help you change the second agent’s port so both can run concurrently. You’re running both as systemd services and the second fails because it’s trying to bind a port already used by the first (commonly the local health-check on 0.0.0.0:8081). Below are concise steps you can follow to change the port for the second agent and restart only that service. 1) Identify which port is conflicting (optional but recommended) • Run on the EC2 host:
Copy code
sudo ss -tulnp | grep LISTEN
or
Copy code
sudo netstat -tulnp | grep LISTEN
• Look for the port reported in the error (e.g., 8081) and note the PID/process. This confirms what to change. 2) Edit the second agent’s systemd service file • Open the service file for the second agent (example path:
/etc/systemd/system/my-agent-2.service
). • Add or update an environment variable or the ExecStart argument that sets the agent’s local port (health/HTTP/metrics port). Example using an environment variable:
Copy code
[Unit]
Description=LiveKit Agent 2
After=network.target

[Service]
Type=simple
Environment="HEALTH_PORT=8082"
ExecStart=/usr/bin/my-agent --health-port ${HEALTH_PORT}
Restart=on-failure
User=ec2-user

[Install]
WantedBy=multi-user.target
• If your agent accepts a different flag (for example
--port
or
--http-port
), replace
--health-port
in ExecStart with the correct flag your agent uses. 3) Reload systemd and start the second service • Run:
Copy code
sudo systemctl daemon-reload
  sudo systemctl restart my-agent-2.service
  sudo systemctl status my-agent-2.service
• Confirm both services are running:
Copy code
sudo ss -tulnp | grep LISTEN
The second agent should now bind the new port (e.g., 8082) and the first agent remains running. 4) Alternative if you cannot change the agent command-line • If the agent binary doesn’t expose a port option, you can: ◦ Wrap it with a small launcher script that sets the port in the environment or passes a different flag. ◦ Run the second agent in a container (Docker) or network namespace so both can use the same internal port without colliding on the host. If you want, share: • The exact error text the second agent shows, • The current content of your second agent’s systemd service file (paste it here), and I’ll give the precise edits tailored to your service file and agent flags.
s
{"message": "worker failed", "level": "ERROR", "name": "livekit.agents", "exc_info": "Traceback (most recent call last):\n File \"/home/ubuntu/IL_Post_Olympiad/sales_env/lib/python3.10/site-packages/livekit/agents/cli/cli.py\", line 1285, in _worker_run\n await server.run(devmode=args.devmode, unregistered=jupyter)\n File \"/home/ubuntu/IL_Post_Olympiad/sales_env/lib/python3.10/site-packages/livekit/agents/worker.py\", line 666, in run\n await self._http_server.start()\n File \"/home/ubuntu/IL_Post_Olympiad/sales_env/lib/python3.10/site-packages/livekit/agents/utils/http_server.py\", line 31, in start\n self._server = await self._loop.create_server(handler, self._host, self._port)\n File \"/usr/lib/python3.10/asyncio/base_events.py\", line 1519, in create_server\n raise OSError(err.errno, 'error while attempting '\nOSError: [Errno 98] error while attempting to bind on address ('0.0.0.0', 8081): address already in use", "timestamp": "2026-01-13T135143.047804+00:00"}
t
Thanks — I see the error: the second agent is failing because it’s trying to bind the default health-check HTTP server to 0.0.0.0:8081, which is already used by the first agent. I’ll help you change the second agent so both can run concurrently without stopping the first. Quick options (pick one) • Change the second agent’s health-check port to a different host port (easy and common). • Bind the second agent’s health-check to a different loopback address (e.g., 127.0.0.2:8081) so the same port can be reused on a different interface. • Run the second agent in isolation (container or separate network namespace) so both can use the same internal port without host conflict. Recommended — change the second agent’s port via systemd (no downtime for the first) 1. Edit the second agent’s systemd service file (example path: /etc/systemd/system/my-agent-2.service). ◦ If your ExecStart accepts a port flag (check the command used in ExecStart), add or change that flag:
Copy code
[Service]
     ExecStart=/path/to/venv/bin/python -m livekit.agents.cli --health-port 8082
Replace
--health-port
with the exact flag your agent binary accepts (if any). • If the agent doesn’t accept a port flag, set an environment variable the agent reads (if supported), for example:
Copy code
[Service]
     Environment="HEALTH_PORT=8082"
     ExecStart=/path/to/your/start-script.sh
And update your start script to pass that env var to the agent. 1. If the agent binary does not expose a configurable port at runtime, use a wrapper script that patches the HTTP server port before starting: ◦ Create /usr/local/bin/start-agent-2.sh:
Copy code
#!/bin/bash
     export PYTHONPATH=/path/to/venv/lib/python3.10/site-packages:$PYTHONPATH
     python - <<'PY'
     # small runtime patch that sets the http server port before starting the agent
     from livekit.agents.utils import http_server
     http_server.HttpServer.__init__.__defaults__ = ("0.0.0.0", 8082)
     from livekit.agents.cli.cli import main
     main()
     PY
• Make it executable: sudo chmod +x /usr/local/bin/start-agent-2.sh • Update systemd ExecStart to run that script. 1. Reload systemd and restart only the second service:
Copy code
sudo systemctl daemon-reload
   sudo systemctl restart my-agent-2.service
   sudo systemctl status my-agent-2.service
Confirm listening ports:
Copy code
sudo ss -tulnp | grep LISTEN
Alternative — bind to a secondary loopback address (if you prefer reusing 8081) 1. Add a loopback alias:
Copy code
sudo ip addr add 127.0.0.2/8 dev lo
1. Make the second agent bind to 127.0.0.2:8081 (via ExecStart flag, environment variable, or a small patch similar to the wrapper above). What I need to give you the precise changes • Paste the current ExecStart line from your second agent’s systemd file (or the whole service file). • Tell me whether the agent binary accepts a port argument (e.g.,
--health-port
,
--port
, etc.) or whether you’re running a Python entrypoint like
python -m livekit.agents.cli
. If you paste your service file now, I’ll return the exact systemd edits and, if needed, a ready-to-use wrapper script you can drop in and run so the second agent starts on port 8082 (or binds to 127.0.0.2:8081) without touching the first agent. Sources: Server options | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation
s
[Unit] Description=AI Agent Service After=network.target [Service] User=root WorkingDirectory=/home/ubuntu/IL_POST_OLYMPIAD_KANNADA Environment="PATH=/home/ubuntu/IL_POST_OLYMPIAD/venv/bin" ExecStart=/home/ubuntu/IL_POST_OLYMPIAD_KANNADA/venv/bin/python3 /home/ubuntu/IL_POST_OLYMPIAD_KANNADA/main.py start --url "wss://ilpresales> Restart=always RestartSec=5 StandardOutput=append:/var/log/IL/post_olympiad_KAN_out.log StandardError=append:/var/log/IL/post_olympiad_KAN_err.log [Install] WantedBy=multi-user.target
t
Thanks — and thanks for pasting your service file. I can help you run a second agent on the same EC2 instance without stopping the first. You’re running the agent with this ExecStart: /home/ubuntu/IL_POST_OLYMPIAD_KANNADA/venv/bin/python3 /home/ubuntu/IL_POST_OLYMPIAD_KANNADA/main.py start --url "wss://ilpresales..." The error shows the agent is trying to bind a local health-check HTTP server to 0.0.0.0:8081, which the first agent already uses. Since your agent command doesn’t show a health-port flag, you have two safe options I recommend (both avoid stopping the first agent). Option A — Change the second agent to use a different port (recommended) 1. Create a small wrapper script that patches the agent’s HTTP server port before starting it. Save as /usr/local/bin/start-agent-2.sh:
Copy code
#!/bin/bash
export PATH=/home/ubuntu/IL_POST_OLYMPIAD/venv/bin:$PATH

python3 - <<'PY'
# Patch HttpServer default host/port before importing the CLI
try:
    from livekit.agents.utils import http_server
    # Change host/port default to 0.0.0.0:8082
    http_server.HttpServer.__init__.__defaults__ = ("0.0.0.0", 8082)
except Exception:
    pass

# Now start the real agent CLI
import sys
sys.argv = ["main.py", "start", "--url", "<wss://ilpresales>"]
from main import main as run_main
run_main()
PY
• Make the script executable: sudo chmod +x /usr/local/bin/start-agent-2.sh 1. Update your second agent’s systemd unit ExecStart to call that script:
Copy code
ExecStart=/usr/local/bin/start-agent-2.sh
1. Reload and restart only the second service:
Copy code
sudo systemctl daemon-reload
sudo systemctl restart your-second-agent.service
sudo systemctl status your-second-agent.service
1. Verify listening ports:
Copy code
sudo ss -tulnp | grep LISTEN
You should now see the second agent using port 8082 while the first remains on 8081. Option B — Bind the second agent to a different loopback address (reuse 8081) If you prefer to keep 8081, bind the second instance to 127.0.0.28081 1. Add a loopback alias:
Copy code
sudo ip addr add 127.0.0.2/8 dev lo
1. Use a wrapper like the one above but set the defaults to ("127.0.0.2", 8081):
Copy code
http_server.HttpServer.__init__.__defaults__ = ("127.0.0.2", 8081)
1. Update systemd ExecStart to run the wrapper, then daemon-reload and restart the second service. Which option would you like to use? • If you choose Option A, I can give a version of the wrapper that preserves any additional CLI arguments you need (or read them from the existing unit). • If you choose Option B, tell me if you want the loopback alias to persist across reboots (I’ll show how to add it to /etc/network/interfaces or a systemd unit). One more small request so I can provide an exact systemd snippet: • What is the second service file name (the filename under /etc/systemd/system)? • Do you need any extra flags passed to main.py beyond the --url shown? I’ll prepare the exact systemd file and wrapper with your chosen port/address.
s
if name == "__main__": opts = WorkerOptions( entrypoint_fnc=entrypoint, agent_name=AGENT_ID, worker_type=WorkerType.PUBLISHER, shutdown_process_timeout=30, initialize_process_timeout=120, port = 8082 ) cli.run_app(opts)
t
Thanks — that code snippet is perfect. I see you’ve set
port = 8082
on
WorkerOptions
before calling
cli.run_app(opts)
. That is exactly the change needed so the second agent binds to 8082 instead of the default 8081. Next steps to make this live and verify both agents run concurrently: 1) Ensure your code change is in the version the systemd service runs • Confirm the file you edited is the same one launched by ExecStart in your service file (
/home/ubuntu/.../main.py
) and that the edited code is saved and committed (if you use version control). 2) Reload systemd and restart only the second agent service • If your service file is named e.g.
ai-agent-2.service
, run:
Copy code
sudo systemctl daemon-reload
  sudo systemctl restart ai-agent-2.service
  sudo systemctl status ai-agent-2.service
• If your unit has a different name, substitute it. 3) Verify the second agent started and is binding the new port • Run:
Copy code
sudo ss -tulnp | grep LISTEN
or
Copy code
sudo netstat -tulnp | grep LISTEN
• You should see: ◦ one process listening on 0.0.0.0:8081 (first agent) ◦ another process listening on 0.0.0.0:8082 (second agent) 4) Check the agent logs for startup confirmation • Tail the second agent’s logs you set in systemd:
Copy code
sudo tail -n 200 /var/log/IL/post_olympiad_KAN_out.log
  sudo tail -n 200 /var/log/IL/post_olympiad_KAN_err.log
• Look for a startup message and absence of the OSError bind error. If you still see a bind error after restarting: • Paste the exact systemd unit filename and the ExecStart line you’re using for the second service. • Paste the
ss
/
netstat
output showing ports in use. I’ll help pinpoint whether the second service is launching the edited code version or if another process is occupying 8082. If you want, I can also provide a short systemd snippet (example unit) or a wrapper script to set the port at runtime instead of editing the code directly. Which would you prefer?