Address already in use bind linux

При повторном запуске сервера — bind: Address already in use

Написал элементарные сервер и клиент на C. Всё работает, но есть одна небольшая проблема. Если соединение первым завершает сервер, то при повторном его запуске bind выдаёт ошибку:
bind: Address already in use
И так примерно минуту при каждой попытке запуска сервера bind выдаёт такую ошибку. По истечении минуты, сервер запускается без ошибок и всё опять работает нормально.
Если соединение завершает клиент, то при повторном запуске сервера ошибок не возникает.

Знающие люди, подскажите пожалуйста, в чём причина такого поведения и как сделать так, чтобы не нужно было ждать перед повторным запуском сервера.

Re: При повторном запуске сервера — bind: Address already in use

Может вы некорректно закрываете соединение?

Re: При повторном запуске сервера — bind: Address already in use

>Может вы некорректно закрываете соединение?

Может быть, хотя я в этом сомневаюсь.

Для демонстрации я написал очень простые версии клиента и сервера. Их можно скачать отсюда:
http://neo.xost.ru/temp/server.c
http://neo.xost.ru/temp/client.c
Скомпилировать их можно так:
gcc -o s server.c
gcc -o с client.c
Испльзуется порт 5555, клиент пытается соединиться к localhost. При запуске в качестве параметров передать время в секундах в течении которого будет поддерживаться соединение. Таким образом если запустить так:
./s 1
./c 2
И когда сервер закроет соединение опять попытаться запустить его:
./s 1
То он выдаст
bind: Address already in use

Re: При повторном запуске сервера — bind: Address already in use

а зачем сервер перезапускать вообще?

делается так:
0. открыли/завязали/etc сокет (socket, bind, listen)
1. получили входящее подключение (accept) и его файловый дескриптор
2. обработали (read, write)
3. закрыли файловый дескриптор соединения (close)
4. если не конец работы сервера, goto 1
5. закрыли сокет (close)

пункты 1-4 можно сделать (и обычно делают) многопоточными (а можно и гланды через select)

Re: При повторном запуске сервера — bind: Address already in use

>а зачем сервер перезапускать вообще?

Это я понимаю. Дело не в том зачем перезапускать. Во-первых интересно почему так происходит. Во-вторых при отладке приходится минуту ждать. А в-третьих под виндой вроде такого нету.

Re: При повторном запуске сервера — bind: Address already in use

>а зачем сервер перезапускать вообще?

Это я понимаю. Дело не в том зачем перезапускать. Во-первых интересно почему так происходит. Во-вторых при отладке приходится минуту ждать. А в-третьих под виндой вроде такого нету.

Re: При повторном запуске сервера — bind: Address already in use

Re: При повторном запуске сервера — bind: Address already in use

Добавил вызов setsockopt, теперь задержки нету. Спасибо! Пойду изучать что делает setsockopt 🙂

Кстати, разве обязательно вызывать shutdown?

Там ничего про обязательный вызов shutdown не написано.

Re: При повторном запуске сервера — bind: Address already in use

Re: При повторном запуске сервера — bind: Address already in use

Благодарю. Прочитал, осознал ширину и глубину проблемы, а также методы её решения 🙂 . Я кстати гуглил, но видать на русском только, потому как такую замечательную статью не нашёл.

Re: При повторном запуске сервера — bind: Address already in use

читаем внмательно Стивенса

Re: При повторном запуске сервера — bind: Address already in use

Про reuseaddr в каждой книжке по сетевому программированию говорится.

Источник

Как побороть » address already in use»

Есть сферический код TCP-сервера на луа:

Подключаюсь к нему с помощью

Если развывать соединение, нажимая Ctrl+C в терминале с nc, то всё норм.

Если же разрывать соединение нажимая Ctrl+C в терминале с сервером, то его последующий запуск вываливается с ошибкой «address already in use» в строке с bind. Через минуту-две запускается нормально

Как побороть «address already in use»? Может подкрутить какие-то опции?

PS: сишников скастовал, потомучто только они разбираются в подобной низкоуровневой магии )

Вышеописанное поведение она не меняет. По-прежнему «address already in use» если тушить сервер при подключенном клиенте

SO_LINGER(с нулевым таймаутом)

reuseaddr влияет если сервер биндится к INADDR_ANY. Но т.к. сокет все-равно в полузакрытом состоянии, законектиться к тому же адресу и тому же порту не получится, пока ОС не отпустит сокет их состояния TIME_WAIT (60 сек, как показывает /proc/sys/net/ipv4/tcp_fin_timeout)

Собственно, переформулируя вопрос из ОП-поста: как повлиять на /proc/sys/net/ipv4/tcp_fin_timeout локально, только для моей програмы?

О, заработало! Спасибо)

убирать time_wait в ноль не очень красиво. навесь обработчик сигнала sigint и с нем рви соединение через tcp rst.

Некрасиво только если потом закрывать ненормально. А если в софте реализован graceful shutdown, то без linger вполне можно жить.

Если же разрывать соединение нажимая Ctrl+C в терминале с сервером

То можно зарегистрировать обработчик соответствующего сигнала. А в нём установить флаг is_shutdown. Теперь после ctrl-c будет вызван обработчик, потом server:accept завершится с ошибкой (EINTR), это можно словить и если флажок is_shutdown взведён, мы знаем, что всё ОК, пользователь хочет всё закрыть, закрываем и выходим

Оффтопик. А вне программы эту проблему можно решить?

Есть некрософт, который давно заброшен разработчиком, но к сожалению в продакшне. Время от времени через него проходят данные, не соответствующие ТЗ, и оно намертво виснет. Давно написал ему watchdog, ( проверяет /proc/$pid/schedstat и /proc/$pid/wchan ), который в случае зависания перезапускает ( при необходимости — убивает по kill -9 ). Но часто при повторном запуске вижу в логах то же самое «address already in use», хотя процесс уже убит. В результате watchdog несколько раз в цикле убивает это говно мамонта, пока тому не удаётся взлететь успешно

Можно ли как-то принудительно очистить состояние порта?

Увы, нет. Это в парафаии ядра, что и настраивается таймаутами на соединение и свойство сокета, опциями SO_REUSEPORT и SO_LINGER. Но любой из этих вариантов имеет последствия. SO_REUSEPORT был разработан в первую очередь для балансировки между несколькими процессами на одном порту, SO_LINGER — непосредственно таймаут в состоянии TIME_WAIT.

Как выше писали, самый лучший вариант — писать обработчик завершения программы по сигналу.

убирать time_wait в ноль не очень красиво

А чем это чревато?

навесь обработчик сигнала sigint и с нем рви соединение через tcp rst.

Пример был сферический. Sigint тоже. Скрипт нужен чтобы тестировать разрывы любимого ростелекома. А тут еще ядро свои разрывы добавляет)

пишу через обработчики уже 10 лет И НИ ЕДИНОГО РАЗРЫВА!!11

миллион способов, все зависит от того насколько «схаченное» решение для вас терпимо. можно сниффать сиквенс намбер и слать tcp rst, например из scapy (из удобного), или даже вроде есть специализированные утилиты. если все зависло так что траффика вообще никакого не проходит (ну, хотя бы кип-алайв зафорсить обычно можно — посылаешь со спуфленного адреса) то тогда можно подглядеть нужный сиквенс намбер прямо в ядре, например через systemtap или кастомным модулем. если же вопрос решается SO_LINGER с нулевым таймуатом, то можно его принудительно установить на сокет — пиши модуль для LD_PRELOAD с перехватом bind() например и устанавливай там дополнительные опции на сокет, я так для одного старого проприетарного говна увеличивал очередь необработанных коннектов.

Какой сигнал сработает когда ростелеком разорвет соединение?)

во-первых, если хочешь получить на свои топики нормальные рабочие ответы, давай в них всю информацию, а то сейчас еще выясниться что речь не про сервер TCP, а еще через две страницу — что и вовсе на самом деле у тебя там винда с SUA.

теперь по делу. если у тебя демон умирает когда говнотелеком рвет соединение, ты что-то делаешь не так. расскажи больше.

Источник

Address already in use

Troubleshooting

Problem

This technote explains why attempts to perform IBM® Rational® ClearCase® operations using local ClearCase server processes results in a failure producing errors such as, albd_server.exe: Error: bind: WINSOCK address already in use, on Microsoft® Windows® or Error: bind: Address already in use, on UNIX® and Linux®.

Symptom

On Windows the Atria Location Broker Daemon (ALBD) service is terminating immediately following startup and the following errors are reported in the Windows® Application log:

—
Albd(9640): Error: Unable to setup "udp" RPC service.
Albd(9640): Error: bind: [WINSOCK] Address already in use
—

—
albd_server.exe: Error: bind: WINSOCK address already in use.
—

On Unix or Linux you may see the following errors in the albd log:

albd_server Error: bind: Address already in use
albd_server Error: Unable to setup "udp" RPC service

Error reported:

Port: 371 is being used by PID:nnn /opt/rational/clearcase/etc/albd_server

Cause

• There may be another application that is using port 371 (TCP/371 and UDP/371) which is reserved for ClearCase, thus, causing a conflict.

Port: 371 is being used by PID:nnn /opt/rational/clearcase/etc/albd_server

Читайте также:  Fatal system error windows subsystem

If you are seeing this error, it may be due to delays in the ALBD service starting, the startup script will try and restart ClearCase again. This process can continue until the processor is running at 100% or until the ALBD service is started. As only one process can lock a port, the first instance of the ALBD process will own the lock and any subsequent instances will be unable to lock the port and, therefore, will report the error.

Diagnosing The Problem

To determine the process holding the port open on Windows:

1. Shut down ClearCase
2. Download tcpview from http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
3. Run the tool
4. Click File/Save as.
5. Save the text out and open it in an editor.
6. Search for "371." This should show you the process with the ports open.

Unix and Linux

At this time, there is no "standard" method to determine the process using a port. Thus, the process is Operating system (and possibly version/distribution) specific.

To determine the process using the albd port on Linux or AIX.

1. Log in as root on the problem server
2. Shut down ClearCase
3. Open a new shell and run

netstat -an | more

When you get output, type

to find the port. Press "n" to move to the next occurrence of this string in case you are not seeing the port.

Note: Each Unix variant and version can have slightly different output for netstat, so care is advised in reading the output.

To determine the process using the port using Solaris:

go to the following URL and collect the script linked to "How can you determine which process is using that port? Otherwise, you must use LSOF."

http://sysunconfig.net/unixtips/solaris.html#ports

Copy the script somewhere the root user can access and ensure that it is executable.

Run the script as follows

Any application listening on port 371 will cause problems for ClearCase. From this output it should be simple to identify and shut down the process in question.

Resolving The Problem

Determine which application is conflicting with ClearCase and shut it down.

You should be able to use the Windows task manager to kill that process, or you could use the "tcpview" tool to kill the process as well.

Note: One Windows application that has been found listening on the albd port is BackWeb (http://www.backweb.com).

One possible cause of this issue is that the albd port may not be registered in the /etc/services or NIS services map may have another application using port 371. To verify this, run one of the following commands:

• ypcat services | grep 371 (if the services are managed via NIS)
• cat /etc/services | grep 371 (if not)

Correct output should look similar to the following:

albd 371/udp # Atria albd_server
albd 371/tcp # Atria albd_server

Lack of output, or multiple assignments of this port, could cause this issue.

For the following error the resolution is to kill the process related to port 371 and restart ClearCase:

Port: 371 is being used by PID:nnn /opt/rational/clearcase/etc/albd_server

Источник