square-flag-66304
02/20/2026, 1:14 PMtall-airline-16756
02/20/2026, 1:14 PMtall-airline-16756
02/20/2026, 1:15 PMwss:// 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 Documentationsquare-flag-66304
02/20/2026, 1:16 PMtall-airline-16756
02/20/2026, 1:17 PM0.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:
sudo netstat -tulnp | grep LISTEN
or
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 Documentationsquare-flag-66304
02/20/2026, 1:19 PMtall-airline-16756
02/20/2026, 1:19 PMMY_AGENT and variable names with your actual names):
1. Edit the service to add or modify an environment variable for the health port:
[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:
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.square-flag-66304
02/25/2026, 5:32 AMtall-airline-16756
02/25/2026, 5:32 AMsudo ss -tulnp | grep LISTEN
or
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:
[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:
sudo systemctl daemon-reload
sudo systemctl restart my-agent-2.service
sudo systemctl status my-agent-2.service
• Confirm both services are running:
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.square-flag-66304
02/25/2026, 6:37 AMtall-airline-16756
02/25/2026, 6:38 AM[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:
[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:
#!/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:
sudo systemctl daemon-reload
sudo systemctl restart my-agent-2.service
sudo systemctl status my-agent-2.service
Confirm listening ports:
sudo ss -tulnp | grep LISTEN
Alternative — bind to a secondary loopback address (if you prefer reusing 8081)
1. Add a loopback alias:
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 Documentationsquare-flag-66304
02/25/2026, 6:39 AMtall-airline-16756
02/25/2026, 6:39 AM#!/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:
ExecStart=/usr/local/bin/start-agent-2.sh
1. Reload and restart only the second service:
sudo systemctl daemon-reload
sudo systemctl restart your-second-agent.service
sudo systemctl status your-second-agent.service
1. Verify listening ports:
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:
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):
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.square-flag-66304
02/25/2026, 6:40 AMtall-airline-16756
02/25/2026, 6:41 AMport = 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:
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:
sudo ss -tulnp | grep LISTEN
or
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:
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?