Привязка сокета домена Unix, адрес повторного использования
Метод #1 - скомпилировать самостоятельно прямо на коробке
Конечно, вы должны быть в состоянии скачать rtmpdump в исходном виде и скомпилировать его на этой коробке, предполагая, что эта коробка имеет необходимые инструменты, такие как gcc для компиляции.
Метод #2 - скомпилировать на другом ящике, скопировать на ящик
Если такой возможности нет, вы можете скомпилировать его на другом сравнимом ящике, т.е. на другом CentOS, а затем использовать scp для копирования полученных двоичных файлов в ваш домашний каталог, возможно в $HOME/rtmpdumpdir, и запустить их оттуда.
Метод #3 - Извлечение содержимого с помощью cpio или rpm2cpio
Вы также можете использовать инструмент командной строки cpio, чтобы взять RPM-файл, содержащий двоичный дистрибутив rtmpdump, и распаковать его в другой каталог, опять же, что-то вроде $HOME/rtmpdumpdir. В частности, есть инструмент под названием rpm2cpio, который может распаковать RPM.
$ rpm2cpio myrpmfile.rpm | cpio -idmv
Другие методы
Есть и другие методы, обсуждаемые в этом вопросе и ответе ServerFault под названием: rpm без root, но я бы не стал ожидать многого от этих методов. Установка пакетов RPM с помощью rpm без root может быть сложной.
References
В этом контексте важно понять, почему ядро имеет состояние TIME_WAITдля соединений TCP. Это состояние предназначено для того, чтобы позволить любым пакетам, связанным с соединением (, которые могли идти по более длинным маршрутам или иным образом задерживаться ), уходить из сети, прежде чем можно будет установить новое соединение на том же порту. Таким образом, вы гарантируете, что новое соединение не получит никаких пакетов, связанных со старым соединением. Параметр reuseaddrпозволяет разработчику сообщить «не выполнять это ожидание».
Сокеты домена Unix не имеют такой проблемы; reuseaddrне имеет смысла в этом контексте.
If the file is not unlink()-ed, even after close, the kernel keeps the associated resources, and the socket is fully functional.
Нет, ядро освободит все ресурсы, связанные с сокетом, когда последний открытый дескриптор этого сокета будет закрыт ()d. Вам нужно только отвязать ()путь, чтобы иметь возможность снова привязать ()к нему.
Since neither close() nor unlink() alone can make a Unix Domain Socket disappear, will both of them do the trick reliably / trigger the kernel to give up all the resources associated with the socket?
См. выше;-)
The unix_domain_socket_inode will live as long as:
- something keeps it open (the socket is not closed), or
- it has the associated path
Нет для 2. Его «связанный путь» можно было бы удалить (разъединить ()ed ), и сокет все еще мог быть доступен через другую жесткую ссылку.
См. мой другой ответ для демонстрации и объяснения.
Похоже, вы перепутали индексный дескриптор сокета (тот, на который указывает фактический fd сокета и который также доступен через/proc/PID/fd/FD)с индексным дескриптором, который может быть связан с (файлом сокета, например/tmp/.X11-unix/X0); они разные, и последний используется только как «точка входа» --, как только связанный с ним сокет закрывается, файл сокета является всего лишь фиктивным индексным узлом в файловой системе.
The file will not appear in the filesystem, if the path starts with the special char \0.)
Если .sun_pathначинается с \0, это уже не путь, а «абстрактный» доменный адрес unix, который, в отличие от путей, может содержать другие \0байты и имеет совершенно другую семантику, (любой может подключиться к сокет, в отличие от доменного сокета Unix в старом стиле -,где подключение к нему зависит от прав доступа к файлу, определяемых его ведущим путем ).
Помните, что эта функция «абстрактного сокета» присутствует только в Linux.