- Bind fails with error 98 (or error 10048)
- The Setup
- Getting the Error Message
- What causes «Address already in use error»
- 1. Another program is using that port
- 2. Your program is already running
- 3. TCP Linger / TIME-WAIT
- Summary
- server: bind failed with error: 10048 #2
- Comments
- Bind failed with error code 10048
- bind failed with: 10048
- Guest
- Guest
- Guest
Bind fails with error 98 (or error 10048)
A common socket programming error I hear about is error 98 (EADDRINUSE) or 10048 (WSAEADDRINUSE) from bind() .
The Setup
Maybe you are programming a server in C or C++. Your socket code might use a setup like this:
If your call to bind fails, the first thing to do is check the error code. The error is stored in errno on Linux, but on Windows you will need to call WSAGetLastError() .
If the error returned by bind() is 98 (Linux) or 10048 (Windows), then it means the local port you are trying to bind to is already in use.
Getting the Error Message
By the way, you can also get the error message in text form.
On Linux it is just a call to strerror() . For error 98, that will return something such as «Address already in use».
Getting the error text on Windows is a bit trickier. There are instructions on getting the Windows error text here. The error message on Windows may be similar to «Only one usage of each socket address (protocol/address/port) is normally permitted.»
In any case, now that you know the what the error is, how do you fix it?
What causes «Address already in use error»
Basically, only one program can listen on a given protocol/address/port tuple at any given time. If more than one program were permitted to listen, then the operating system wouldn’t know which program to send incoming connections to.
When I hear about this error from readers, there is usually one of three causes.
1. Another program is using that port
The most obvious cause for the error is that another program is using the port you want to listen on. In this case, you can change the port your program listens on, or you can close the other program that is using that port.
On Linux, you can see which other programs are listening for connections using the netstat -ntlp command. The ntlp stands for «numeric tcp listen programs». In order words, we are asking netstat to show port numbers (numeric), to only show TCP sockets, to only show sockets in the listening state, and to show which programs are using the sockets.
The following screenshot shows using the netstat command on Linux to find which program is tying up port 8080.
As you can see above, the program tying up port 8080 is «server1» with a PID of 96939. Knowing the PID, you can easily kill the program if you like. Just please be sure you know what the program is and whether you really need it or not before you go around terminating things willy-nilly.
Windows also has a netstat command, but the usage is different. On Windows you can show all listening sockets with the command netstat -nao -p TCP | findstr LISTEN . Window’s netstat command doesn’t have an easy way to filter only listening sockets, so the findstr program comes in handy. In any case, running that command will list each listening TCP socket and show the owner program’s PID for each socket.
The following screenshot shows the usage of netstat on Windows to see which program is using port 8080:
As shown in the above screenshot, netstat lists each program’s listening address and PID. You can get more info on a PID with the tasklist command. For example, running tasklist | findstr 50396 would get us the program name for PID 50396 — the process we identified as using port 8080. For example:
The above screenshot shows that the program «server1.exe» has the PID of 50396, and therefore is the program using port 8080.
2. Your program is already running
This is more common than you think. Is your program already running? If it is, then of course the port is already in use!
This also isn’t always as easy to determine as you might like. In the server world, it’s very common for programs to run in the background or as daemons. In any case, if you get a bind() error or address already in use error, be sure to check that your program isn’t already running.
3. TCP Linger / TIME-WAIT
I’ve saved the most complicated scenario for last. Suppose your server program is running, and then you terminate it (or it crashes). When you restart it, you get the address in use error (EADDRINUSE or WSAEADDRINUSE). However, if you wait a couple minutes, you are able to start your program without error. What is going on here?
I won’t go into too much depth here (read my book for that), but basically when a socket is closed it can go into a TIME-WAIT state on the end that initiated the close. This isn’t a problem for a client program, since it doesn’t use bind() anyway (typically). However, this TIME-WAIT state can be a problem for server applications. It means the operating system is still keeping track of the closed socket, even after your entire program is closed. This is enough to cause the «Address already in use» error if you restart your program.
Now, there is an easy way to prevent this error on Linux. You can use the SO_REUSEADDR socket option before calling bind() . It looks like this:
This option will allow bind() to succeed even if a few TIME-WAIT connections are still around. There is very little downside to using the SO_REUSEADDR on Linux, so I suggest most server applications use it in that environment.
There is a major drawback to using this option on Windows. When using SO_REUSEADDR on Windows, the OS will simply allow multiple programs to bind to the same port. When an incoming connection is routed, it will only go to one program. This doesn’t mean you shouldn’t use SO_REUSEADDR on Windows, but you should certainly be aware of this behavior.
In any case, check out Chapter 13 of my book for more information.
Summary
If bind() causes error 98 (EADDRINUSE) or 10048 (WSAEADDRINUSE), it means you are trying to bind to a local port that is already in use. This is usually caused by one of three reasons:
- Another program is already using that port.
- Your program is already running and you’ve attempted to start it a second time.
- Your program was running recently and some connections are still lingering around in the half-dead TIME-WAIT state.
Cause 1 can be fixed by terminating the program using your port, or having your program use a different port.
Cause 2 can be fixed by only running one instance of your program at a time.
Cause 3 can be fixed by waiting a few minutes or by using the SO_REUSEADDR socket option on Linux. The SO_REUSEADDR option has the drawback on Windows that it will allow multiple programs to listen on the same port, but only one will actually receive connections.
I hope you found this article helpful. I’d love to hear any feedback you might have. Don’t hesitate to get in touch.
If you found this information helpful, you might be interested in my book.
server: bind failed with error: 10048 #2
Comments
I get the error server: bind failed with error: 10048 (port for remote management is busy, use different -mport value), next attempt in 20sec.
I am using windows and configured it as you said.
The text was updated successfully, but these errors were encountered:
Did you get the error on the no-fee-proxy window ?
It seems the port is already taken by the remote management engine.
Can you change the proxy port ? or change the claymore’s remote port (with -mport argument)
Yes, the error was in the proxy window. I can try and change one, and then the other and let you know.
This is just an issue on one of my rigs. The other rigs get different issues.
There are some weird connection issues with my other boxes as well. Most of the time they revert to the epools.txt. I can tell because I set a different name in the epools.txt so I can see in the pool display if they failed over.
They everyone one of my boxes fails over at least once an hour.
Are you using ethos by chance?
No, this is all on Windows.
I would be glad to help trouble shoot all of the issues I am experiencing. This is such a great project and I would like to help work the kinks out.
What can I do to assist?
I added you as a contributor, feel free to make changes as you see fit. I have some time to debug this tomorrow, also feel free to dm me in a gitter or something.
Bind failed with error code 10048
Сообщения: 1545
Благодарности: 48
Petya V4sechkin, в общем проблема оказалась в безобидном VNC-сервере. Он работает как служба.
Не понимаю, чем мог помешать VNC-сервер? Он занимает конкретные порты 5800 и 5900. И все.
А причем тут вышеуказанный порт 10048 тогда?
Каждый раз тушить VCN как-то нехорошо.
| Конфигурация компьютера |
| Материнская плата: ASUS P8Z77-V LE PLUS |
| HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб |
| Звук: Realtek ALC889 HD Audio |
| CD/DVD: ASUS DRW-24B5ST |
| ОС: Windows 10 Pro x64 |
| А причем тут вышеуказанный порт 10048 тогда? |
Это не порт, а код ошибки Winsock.
| Он занимает конкретные порты 5800 и 5900 |
Это сообщение посчитали полезным следующие участники:
| Порты можно изменить в настройках. » |
Изменил в на сервере VNC порт 5800 на 5801 — теперь проблемная программа работает.
Но что интересно, то запущенный процесс от этой программы (TransData.exe) не занимает ни один порт, о чем свидетельствует netstat -aon. Также юзал tcpview — там процесс TransData.exe не отображается.
Т.е. может быть такое, что при запуске программа смотрит наличия доступа на порт 5800 и если его нет, то не стартует. Иначе же запускается, но порт не занимает.
? 
| Конфигурация компьютера |
| Материнская плата: ASUS P8Z77-V LE PLUS |
| HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб |
| Звук: Realtek ALC889 HD Audio |
| CD/DVD: ASUS DRW-24B5ST |
| ОС: Windows 10 Pro x64 |
| не занимает ни один порт, о чем свидетельствует netstat -aon. Также юзал tcpview |
Это сообщение посчитали полезным следующие участники:
