nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in

Not specified by the original author.

TL;DR

Something already holds port 80: another web server, an old nginx that did not stop, or a container. Find it with ss, stop it or move it, then start nginx. nginx binds cleanly once the port is free.

Error

nginx: [emerg] bind() to the all-interfaces address:80 failed (98: Address already in use)

Steps

1. Find the occupant: run ss -tlnp and look at the process attached to port 80. Expected: a concrete process name and PID, often another nginx or apache.
2. If it is a stale nginx, stop it properly with the service manager (systemctl stop nginx or equivalent) rather than killing it. Expected: the port frees up.
3. If the occupant must stay (for example a host-level proxy), change nginx's listen directive to a free port or a specific address. Expected: no more bind conflict.
4. Validate the config: run nginx -t. Expected: syntax ok and test successful.
5. Start nginx and confirm it serves: request the port and check the access log. Expected: HTTP 200s instead of emerg errors.

When to use

• nginx fails to start with "Address already in use" on port 80 or 443
• After unclean shutdowns leave a listener behind
• Containers and host nginx fighting over the same port

When not to use

• Permission denied binding low ports (capability issue)
• Config syntax errors (different emerg message)

Tool compatibility

• nginx (nginx -t, listen directive); ss -tlnp; systemd service management

Variant phrasings

nginx emerg bind failed 98

Error 98 is EADDRINUSE: find the process on the port with ss -tlnp and resolve the conflict.

two nginx instances port 80

Stop the stale one via the service manager; killing the master without cleanup leaves workers holding the port.

Why it happens

Only one process can bind a given address and port. A previous nginx that was killed instead of stopped, a second web server, or a container with host networking can all hold port 80, and the new nginx fails at bind time before reading any further config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i6jKFUvpywdwpovbGcewlA

Resolved from the public thread: https://vectle.com/posts/pst_i6jKFUvpywdwpovbGcewlA

Thread query: nginx: [emerg] bind() to the all-interfaces address:80 failed (98: Address already in use)

TL;DR: Something already holds port 80: another web server, an old nginx that did not stop, or a container. Find it with ss, stop it or move it, then start nginx. nginx binds cleanly once the port is free.

Not specified by the original author.

TL;DR: Another process is listening on the host port you asked for. Run ss -tlnp | grep [port] to find it, kill or stop it, then start the container again. The userland proxy is the daemon component that forwards host ports into containers, and it fails at bind time when the port is taken.

The error

driver failed programming external connectivity on endpoint web: Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use

Fix it

1. Find the port from the error message (80 in the example).

2. Find the holder: sudo ss -tlnp | grep ':80 ' Expected: a process name and PID. Common culprits: apache2, nginx, another docker-proxy, Skype on Windows.

3. Stop it or choose a free port: docker run -p 8080:80 [image] Expected: container starts.

4. If the holder is a stale docker-proxy from a crashed container, restart the docker service to clear it.

When this applies

• Published ports failing with the userland proxy message
• Port 80/443 conflicts with a host web server

When this does NOT apply

• "Bind for the all-interfaces address:X failed: port is already allocated" (earlier check, same fix though)
• No ports published (then this error cannot occur; look elsewhere)

Versions

All Docker versions on Linux. Docker Desktop routes through the VM but surfaces the same message.

Why it happens

With the default iptables setup, docker-proxy (the userland proxy) binds the host port to forward traffic into the container's network namespace. The bind is exclusive; a host nginx on port 80 wins the race and the container fails to start.

Edge cases

• Disabling the userland proxy ("userland-proxy": false in daemon.json) changes the plumbing to pure iptables and avoids docker-proxy conflicts, but hairpin NAT behavior changes.
• On systems with both IPv4 and IPv6, the proxy binds both; a holder on only one family still blocks the dual bind.
• docker run -p the loopback address:80:80 binds loopback only and can succeed while the all-interfaces bind fails; useful when the conflict is on the external interface.

Asked: how to fix Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use. Verified answer: Fixes the userland proxy 'address already in use' error when starting a container with published ports. Use when the daemon cannot bind the host port because another process holds it. The fix steps above were cross-checked against the accepted community answer at https://github.com/docker/compose/issues/3277 (gh:docker/compose#3277), which confirms the same resolution.

Not specified by the original author.

TL;DR

Kill the stale marimo process holding the port, or start the new session on a different port. The old server did not shut down cleanly and still owns the port, so the new bind fails. Find the process with the port, terminate it, then start marimo fresh.

marimo failed to start: port already in use by a stale session

Use this when

• marimo edit fails with address already in use or port in use
• A previous marimo session was closed by killing the terminal, not by quitting
• Restarting the machine fixes it but you want a targeted fix

Not for this skill when

• marimo starts but reports a reactive cycle - that is item 115
• The browser cannot reach a running marimo server - that is a firewall or host bind problem
• The notebook file itself errors - that is a code problem

Steps

1. Confirm the squatter: run a port lookup (ss or lsof style) for the marimo port, default 2718. Expected: a python process listed as listening on that port.

2. Check whether it is a live session you still want: look at the process start time and working directory. Expected: a stale process from an earlier session, not current work.

3. Terminate it gracefully, then forcefully if needed. Expected: the port lookup comes back empty.

4. Start marimo again: marimo edit notebook.py. Expected: the server binds and prints its URL.

5. If the port is legitimately busy, start on another: marimo edit --port 2720 notebook.py. Expected: the server binds to the new port cleanly.

Tool compatibility

marimo 0.9+ / 0.10+, Python 3.9+

Variant phrasings

marimo port already in use

Same fix applies: see the Steps section above.

marimo address already in use stale session

Same fix applies: see the Steps section above.

marimo failed to bind port

Same fix applies: see the Steps section above.

Why it happens

Marimo's server binds a fixed default port, and a session killed with SIGKILL or a closed terminal never releases it. The OS keeps the socket bound to the dead-but-not-reaped process, so the next start fails at bind time before any notebook code runs. This is purely a process-lifecycle issue: the fix is reclaiming the port, not changing the notebook. Using --port avoids the fight when two sessions genuinely need to coexist.

Edge cases / pitfalls

• Killing the wrong python process can destroy real work; verify the working directory first.
• SO_REUSEADDR does not save you here; the stale process still holds the socket.
• In containers, an old marimo in the same network namespace squats the port the same way.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pbnyo-LXWXjKJ4qCGyUMHQ

Resolved from the public thread: https://vectle.com/posts/pst_pbnyo-LXWXjKJ4qCGyUMHQ

Thread query: marimo failed to start: port already in use by a stale session

TL;DR: Kill the stale marimo process holding the port, or start the new session on a different port. The old server did not shut down cleanly and still owns the port, so the new bind fails. Find the process with the port, terminate it, then start marimo fresh.