Я нашел решение. Сценарий удара, кажется, производит вход (А именно, 'c' ключ), который вмешивается в ffmpeg
процесс.
Добавление < /dev/null
к ffmpeg
командная строка, как так:
ffmpeg -i "./$f" -vcodec libx264 -vprofile high -preset slow -b:v 500k -maxrate 500k -bufsize 1000k -threads 0 -acodec libfaac -ab 128k "./mp4s/$MP4FILENAME" < /dev/null
устраняет проблему.
Я нашел решение здесь: http://www.g-loaded.eu/2006/11/24/auto-closing-ssh-tunnels/
Как это было упомянуто ранее, вместо того, чтобы использовать-f-N комбинация переключателя, мы можем просто использовать-f один, но также и выполнить команду на удаленной машине. Но, какая команда должна быть выполнена, так как мы только должны инициализировать туннель?
Это - когда сон может быть самой полезной командой всех! В этой конкретной ситуации сон имеет два преимущества:
То, как они помогают в автозакрытии туннеля ssh, объяснено ниже.
Мы запускаем ssh сессию в фоновом режиме при выполнении команды сна в течение 10 секунд на удаленной машине. Число секунд не крайне важно. В то же время мы выполняем vncviewer точно как прежде:
[me@local]$ ssh -f -L 25901:127.0.0.1:5901 me@remote.example.org sleep 10; \
vncviewer 127.0.0.1:25901:1
В этом случае ssh клиент проинструктирован, чтобы разветвить ssh сессию к фону (-f), создать туннель (-L 25901:127.0.0.1:5901) и выполнить команду сна на удаленном сервере в течение 10 секунд (сон 10).
Различие между этим методом и предыдущим (-N переключатель), в основном, то, что в этом случае основная цель ssh клиента не состоит в том, чтобы создать туннель, а скорее выполнить команду сна в течение 10 секунд. Создание туннеля является некоторым побочным эффектом, вторичной целью. Если бы vncviewer не использовался, то ssh клиент вышел бы после периода 10 секунд, поскольку он больше не имел бы заданий, чтобы сделать, уничтожая туннель одновременно.
Во время выполнения команды сна, если другой процесс, vncviewer в этом случае, начинает использовать тот туннель и сохраняет занятым вне периода 10 секунд, то, даже если ssh клиент заканчивает его удаленное задание (выполнение сна), это не может выйти, потому что другой процесс занимает туннель. Другими словами, ssh клиент не может уничтожить туннель, потому что он должен был бы уничтожить vncviewer также. Когда vncviewer прекращает использовать туннель, затем ssh клиент выходит также, поскольку он уже выполнил свою цель.
Таким образом, никакие процессы ssh не оставляют, работая в фоновом режиме.
Для уничтожения туннеля использовать ps -C ssh
или ps | grep ssh
или любой другой вариант для определения, какой процесс ssh выполняет туннель. Затем уничтожьте его.
С другой стороны, можно искать процесс путем определения, какой имеет этот открытый порт:
netstat -lnpt | awk '$4 ~ /:1234$/ {sub(/\/.*/, "", $7); print $7}'
Если Вы хотите уничтожить все ssh клиенты, работающие на Вашей машине (как Ваш пользователь), pkill ssh
сделает это.
Особенно хорошее решение для сценариев - это использовать Master Mode
, с розеткой для команд управления:
ssh -f -N -M -S <path-to-socket> -L <port>:<host>:<port> <server>
снова закрыть его:
ssh -S <path-to-socket> -O exit <server>
Это позволяет избежать оба для идентификаторов процессов и любых вопросов времени, которые могут быть связаны с другими подходами.
Лучшим решением, которое я нашел для уничтожения всех туннелей в одной командной строке, является
ps -lef|grep ssh|grep "\-L"|awk '{print $4}'|xargs kill
для сеансов ssh просто удалите параметр туннеля
ps -lef|grep ssh|awk '{print $4}'|xargs kill
Когда я запускаю туннель с:
ssh -fN -D 8080 SOME_IP_HERE -l LOGIN_NAME_HERE
-f
Запрашивает переход ssh в фоновый режим непосредственно перед выполнением команды. -N
Не выполнять удаленную команду. Это полезно только для перенаправления портов. -D
Определяет локальное «динамическое» перенаправление портов -на уровне приложения. -l
Указывает пользователя для входа в систему как на удаленной машине. Я могу закрыть его с помощью:
ps -lef | grep ssh | grep "8080" | awk "{print \$2}" | xargs kill
Я нашел надежное решение на SO, см.:https://stackoverflow.com/a/26470428. Все заслуги принадлежат @ghoti.
Надеюсь, меня простят за то, что я не повторил всей истории. Он основан на «расширенном» параметре конфигурации SSH ControlMaster
, который лучше всего указать в файле ~/.ssh/config
. Вот как я сделал это для VNC -через -SSH (В VPN моего работодателя закрыты все порты, кроме SSH и HTTPS ).
~/.ssh/config
часть (обратите внимание на записи ControlMaster
и ControlPath
:
Host vnc
HostName my.desktop.internal.within.company
User laryx
IdentityFile ~/.ssh/id_ecdsa
LocalForward 5999 127.0.0.1:5900
RequestTTY no
ExitOnForwardFailure yes
ControlMaster auto
ControlPath ~/.ssh/control_sockets%r@%h:%p
Я подключаюсь/отключаюсь с помощью небольшого скрипта Bash:
#!/bin/bash
if [ $# -lt 1 ]; then
echo "This script creates an SSH tunnel to my desktop"
echo "so that I can share its screen via VNC-over-SSH"
echo "Usage: $0 start|stop"
echo "Remember to start VPN first!"
exit 1
fi
if [ $1 == "start" ]; then
# Assuming that the VPN connection has been established
# 1) Start the tunnel with
ssh -f vnc -N
# 2) check it
ssh -O check vnc
echo "Now share the screen by connecting to 'vnc://localhost:5999'"
exit 0
fi
if [ $1 == "stop" ]; then
ssh -O exit vnc
echo "Now you may exit the VPN"
exit 0
fi
Туннель управляется с помощью команд ssh -O
.
vncviewer 127.0.0.1::25091
поскольку Вы используете синтаксис порта а не синтаксис дисплея. – Christian Wolf 26.09.2013, 13:07