У меня возникли трудности с повторным подключением к сеансу экрана, поэтому я попытался убить сеанс экрана клиента и повторно подключиться к сеансу сервера. Это не удалось. Потом я сделал что-то глупое. Сделал -wipe. Теперь у меня нет файла именованного канала в /tmp/uscreens/... каталог.
Сервер экрана все еще работает, и мне было интересно, можно ли каким-то образом воссоздать именованный канал.
Я использую версию экрана 4.00.03 (FAU) 23 октября 2006 года, работающую под управлением cygwin под управлением Win7 Home Premium. Хотя я мог бы оправиться от убийства экрана и детей, я бы предпочел этого не делать.
Любые идеи?
РЕДАКТИРОВАТЬ: Вот список из моего каталога fd:
$ ls -l /proc/8728/fd/ total 0 lrwxrwxrwx 1 Adrian None 0 May 12 22:32 0 -> /dev/null lrwxrwxrwx 1 Adrian None 0 May 12 22:32 1 -> /dev/null lrwxrwxrwx 1 Adrian None 0 May 12 22:32 10 -> /dev/ptmx lrwxrwxrwx 1 Adrian None 0 May 12 22:32 11 -> /cygdrive/c/Users/Adrian/Downloads/arduino-1.0.3-windows/Projects/RangeDetector5/screenlog.2 lrwxrwxrwx 1 Adrian None 0 May 12 22:32 2 -> /dev/null lrwxrwxrwx 1 Adrian None 0 May 12 22:32 3 -> /tmp/uscreens/S-Adrian/8728.pty0.TARDIS lrwxrwxrwx 1 Adrian None 0 May 12 22:32 4 -> /dev/pty0 lrwxrwxrwx 1 Adrian None 0 May 12 22:32 5 -> /var/run/utmp lrwxrwxrwx 1 Adrian None 0 May 12 22:32 6 -> /dev/ptmx lrwxrwxrwx 1 Adrian None 0 May 12 22:32 7 -> /cygdrive/c/Users/Adrian/Downloads/arduino-1.0.3-windows/Projects/RangeDetector5/screenlog.0 lrwxrwxrwx 1 Adrian None 0 May 12 22:32 8 -> /dev/ptmx lrwxrwxrwx 1 Adrian None 0 May 12 22:32 9 -> /cygdrive/c/Users/Adrian/Downloads/arduino-1.0.3-windows/Projects/RangeDetector5/screenlog.1
Ситуация здесь:
start cmd: # ps -o pid,args -p 4629 --no-headings
4629 SCREEN
start cmd: # ls -l /proc/4629/fd | grep socket
lrwx------ 1 root root 64 13. Mai 02:55 4 -> socket:[90202]
start cmd: # lsof -n | grep 90202
screen 4629 [...] 90202 /var/run/screens/S-root/4629.pts-12.inno
Думаю, то, что вы удалили, эквивалентно моему /var/run/screens/S-root/4629.pts-12.inno. ls -l /proc/$PID/fd все еще может указывать на узел сокета. Если вы удалите файлы, вы можете получить их содержимое через /proc/$PID/fd пока процесс держит их открытыми. Я не знаком с сокетами, но вы можете хотя бы попробовать: вы можете создать символическую ссылку (вместо удаленного сокета), которая указывает на дескриптор сокета в /proc/$PID/fd.
Изменить 1:
Может быть недостаточно установить символическую ссылку на сокет, потому что клиентский процесс может проверить тип файла и найти символический знак там, где он ожидает сокет, и, таким образом, прервать выполнение без проверки цели символической ссылки.
Возможно, эту проблему можно решить с помощью socat. Эта программа позволяет "переадресацию сокетов". Я только что протестировал (с gpg-agent вместо того screen хотя; и исходный сокет не был удален):
start cmd:> echo $GPG_AGENT_INFO
/tmp/gpg-DMOHGo/S.gpg-agent:3236:1
# next command in another shell
start cmd:> socat UNIX-LISTEN:gpg-agent-socket UNIX-CONNECT:/tmp/gpg-DMOHGo/S.gpg-agent
start cmd:> GPG_AGENT_INFO=/home/hl/tmp/gpg-agent-socket:3236:1
start cmd:> start cmd:> gpg-connect-agent
>
Это может работать с подключенным FD в /proc, слишком. Кроме того, socat поддерживает FIFO (именованные каналы).
Изменить 2:
Он также работает с FIFO:
socat PIPE:/proc/8728/fd/3 PIPE:/tmp/uscreens/S-Adrian/8728.pty0.TARDIS
стоит сделать.
Кстати: даже если это не решит вашу проблему (пока), я действительно думаю, что усилия и качество моего ответа должны, по крайней мере, стоить одобрения ...