Error: start api listener error: listen tcp bind: address already in use

While monitoring log, I got the following error after starting Chirpstack Network Server:

root@testuser-Vostro-3902:~# chirpstack-network-server  --log-level 4
INFO[0000] starting ChirpStack Network Server            band=EU868 docs="" net_id=000000 version=3.11.0
INFO[0000] storage: setting up storage module
INFO[0000] storage: setting up Redis client
INFO[0000] storage: connecting to PostgreSQL
INFO[0000] storage: applying PostgreSQL data migrations
INFO[0000] storage: PostgreSQL data migrations applied   count=0
INFO[0000] gateway/mqtt: connecting to mqtt broker       server="tcp://localhost:1883"
INFO[0000] backend/gateway: connected to mqtt server
INFO[0000] gateway/mqtt: subscribing to gateway event topic  qos=0 topic=gateway/+/event/+
INFO[0000] api: starting network-server api server       bind="" ca-cert= tls-cert= tls-key=
FATA[0000] setup network-server api error: start api listener error: listen tcp bind: address already in use

I found some people are facing same kind of issue on the web, but nothing seems to work for me. So can anyone explain how to resolve this? Also Can I use another random port number to bind to, instead of 8000?

I would check what you have already running on 8000.

netstat -tlnp|grep 8000

1 Like

While chirpstack network server service in up and running, I get

root@testuser-Vostro-3902:~# netstat -a | grep 8000
tcp        0      0 localhost:59144         localhost:8000          ESTABLISHED
tcp6       0      0 [::]:8000               [::]:*                  LISTEN
tcp6       0      0 localhost:8000          localhost:59144         ESTABLISHED

After stopping the service,

root@testuser-Vostro-3902:~# netstat -a | grep 8000

which indicates that there is no process using port 8000.
But as soon as I start the service again, it is conflicting itself to use the same port.
I have re-installed the chirpstack server on my machine a couple of times after cleaning all the dependencies line databases used, redis cache, e.t.c. Is there any chance for this re-installation to cause this kind of problem?

Also I am not able to see Downlink payload messages on my Application Server GUI, but at the end-node side I am seeing the responses. Is this anyway linked with the above error?