ssh команда с другой машины
sudo wget https://yt-dl.org/downloads/latest/youtube-dl -O /usr/local/bin/youtube-dl
sudo chmod a+rx /usr/local/bin/youtube-dl
Вы также можете использовать pip:
sudo pip install --upgrade youtube_dl
Источник: официальный сайт youtube-dl
Я предпочитаю скачивать с помощью wget. Пип не нужен. Но вам понадобится python (который уже установлен).
Бонус:
youtube-dl youtube_playlist_link --playlist-items 3,5,6,8 -g -f best' > list_url.txt
Этот фрагмент кода пытается получить 3-е, 5-е, 6-е и 8-е видео плейлиста и поместить их в list_url.txt, который вы можете использовать позже с некоторой загрузкой. управляющий делами .
ssh -T MACHINEB SCRIPT &поддерживает соединение SSH, пока работает SCRIPT. Это необходимо, потому что:
- Если SCRIPT производит какие-либо выходные данные, SSH должен передать их хосту.
- Если SCRIPT считывает ввод, SSH должен ретранслировать его с хоста. Это может быть немного тонко .
- Когда SCRIPT завершает работу, SSH передает клиенту свой статус выхода, и процесс
sshзавершается с этим статусом.
Если соединение прервется, это не повлияет на SCRIPT, если он не будет пытаться читать или писать в stdin, stdout или stderr. Поскольку терминал не задействован, SCRIPT не будет уничтожен SIGHUP при разрыве соединения. Однако, если SCRIPT попытается, скажем, напечатать сообщение об ошибке, это сообщение пройдет через соединение.
Вы должны сделать одно из двух.
Метод пакетного задания :убедитесь, что SCRIPT не принимает никаких входных данных и записывает стандартный вывод и стандартные ошибки в файл.
ssh -T MACHINEB 'myprogram </dev/null >myprogram.log 2>&1'Интерактивный метод :запустить СЦЕНАРИЙ внутри мультиплексора экрана:Экран или tmux .
ssh -T MACHINEB screen -S somename -dm myprogramВы можете увидеть, как работает ваша программа, подключившись к этому экранному сеансу.
ssh MACHINEB screen -S somename -drСеанс screen завершается при выходе из программы. Чтобы сохранить его для просмотра вывода и ошибок программы, см. Предотвратить завершение сеанса экрана GNU после завершения исполняемого скрипта
См. также Выполнение удаленных команд,полное отсоединение от ssh-соединения
Ваш вопрос не очень ясен и немного запутан, но я постараюсь дать несколько ответов, чтобы прояснить для вас ситуацию. Во-первых, обратите внимание, что процесс sshвыполняется на MACHINEA, а SCRIPT — на MACHINEB. Таким образом, знак «&» помещает командный процесс sshна MACHINEA в фоновый режим -, а не процесс оболочки SCRIPT (), который вы запускаете на MACHINEB. Таким образом, основной сценарий ()на MACHINEA продолжает выполнять следующие команды основного сценария (), в то время как MACHINEB работает в сеансе "ssh" -на переднем плане, что касается MACHINEB.. Таким образом, если у вас есть проблема с подключением от A к B, ваша команда sshне остановит основной сценарий на MACHINEA -, потому что процесс sshвыполняется (, возможно, завис )в фоновом режиме.
Когда вы запускаете сценарий, он создает подоболочку, в которой выполняется команда. Любые процессы, включая запущенные фоновые процессы, такие как команда ssh, присоединяются к этой подоболочке. Если подоболочка завершается, фоновый процесс также уничтожается. Вместо этого попробуйте запустить процесс ssh как команду nohup в сценарии 1. Ответ, вдохновленный:Запустите фоновый процесс из сценария и управляйте им, когда сценарий завершится
Команды, отправленные через ssh, присоединяются к процессу ssh, и процесс ssh должен продолжать работать, чтобы команды могли выполняться. Выход из процесса ssh приведет к завершению любых фоновых процессов на машине B, поскольку они подключены к подоболочке, созданной для сценария 2. Здесь также пригодится Nohup.
Но поскольку ваш процесс выполняется на машине B, но, по-видимому, зависает и не завершается преждевременно, преждевременное завершение процесса ssh не кажется проблемой.
Проблемы с сетью также маловероятны, поскольку они, скорее всего, завершат процесс ssh и прекратят процессы, запущенные на машине B. Кроме того, если проблемы с сетью не настолько серьезны, чтобы остановить процесс ssh, они не должны влиять на процессы, работающие на машине. B. Вероятно, что-то в сценарии 2 на машине B вызывает зависание. Один из способов доказать, что эта логика неверна, — завершить процесс ssh на машине A и посмотреть, что произойдет на машине B.
Наконец, лучше всего запустить команду ssh в качестве процесса nohup, как было предложено в предыдущей ссылке. Кроме того, если ваши команды в сценарии 2 не зависят друг от друга последовательно, я бы также запускал каждую из них, используя nohup.(https://askubuntu.com/questions/349262/run-a-nohup-command-over-ssh-then-disconnect). Я предполагаю, что ничто в сценарии 1 на машине A не зависит от выполнения сценария 2, основываясь на том факте, что у вас есть команда ssh, работающая как фоновый процесс.