Как сделать чтобы при закрытии ssh программа работала

Обновлено: 07.07.2024

Допустим, я запускаю кучу процессов из ssh-сессии. Можно ли завершить сеанс ssh, сохраняя эти процессы на удаленном компьютере?

Вы должны искать современные альтернативы, такие как tmux .

tmux превосходит screen по многим причинам, вот лишь некоторые примеры:

Окна могут быть перемещены между сеансами и даже связаны с несколькими сеансами
Окна можно разбить по горизонтали и вертикали на панели
Поддержка цветных терминалов UTF-8 и 256
Сеансы можно контролировать из командной консоли без необходимости входа в сеанс

Основная функциональность

Чтобы получить ту же функциональность, которая описана в answer рекомендация screen , вам необходимо сделать следующее:

sSH в удаленной машине
запустите tmux , напечатав tmux в командной консоли
запустите нужный процесс внутри запущенного сеанса tmux
оставить/отменить сеанс tmux , набрав Ctrl + b а потом d

Теперь вы можете безопасно выйти из системы с удаленного компьютера, ваш процесс продолжит работать внутри tmux . Когда вы вернетесь снова и захотите проверить состояние вашего процесса, вы можете использовать tmux attach , чтобы присоединиться к вашему сеансу tmux .

Если вы хотите, чтобы несколько сеансов работали параллельно, вам следует называть каждый сеанс, используя Ctrl + b и $ . Вы можете получить список запущенных в данный момент сеансов, используя tmux list-sessions , теперь присоедините к запущенному сеансу с помощью команды tmux attach-session -t 0 .

tmux может делать гораздо более сложные вещи, чем обрабатывать одно окно за один сеанс. Для получения дополнительной информации загляните в man tmux или страница tmux GitHub . В частности, вот часто задаваемые вопросы об основных различиях между screen и tmux .

Вариант 1: Nohup

Лучший способ часто самый простой.

Это было сделано специально для этого, он даже записывает стандартный вывод в Nohup.log .

Вариант 2: bg

перевести вашу последнюю приостановленную задачу в фоновый режим, чтобы она продолжала выполняться.

Затем быстрое disown должно поддерживать выполнение процесса после выхода из системы.

screen и другие могут сделать это, но это не то, для чего они. Я рекомендую Nohup для задач, которые вы собираетесь оставить, и bg для задач, которые вы уже выполняете и не хотите перезапускать.

Имейте в виду, что оба bash специфичны. Если вы не используете bash, то команды могут отличаться.

Вы можете сделать это, используя screen .

Введите man screen , чтобы узнать больше, или прочитайте это страница справки экрана .

sSH в ваш удаленный ящик. Введите screen Затем запустите нужный процесс.

Нажмите Ctrl - A затем Ctrl - D , Это "отсоединит" ваш сеанс экрана, но оставит ваши процессы запущенными. Теперь вы можете выйти из удаленного окна.

Если вы хотите вернуться позже, войдите снова и введите screen -r . Это "возобновит" ваш сеанс экрана, и вы сможете увидеть результаты вашего процесса.

Screen и Nohup - лучший способ, но если вам нужно отсоединить процесс, уже запущенный без экрана или Nohup, вы можете запустить команду disown.

disown [-ar] [-h] [ jobspec … | pid … ]

Без параметров удалите каждое jobspec из таблицы активных заданий. Если задана опция -h , задание не удаляется из таблицы, но помечается так, что SIGHUP не отправляется заданию, если оболочка получает SIGHUP. Если jobspec отсутствует и не указана ни опция -a , ни опция -r , используется текущее задание. Если не указано jobspec, опция -a означает удаление или пометку всех заданий; опция -r без аргумента jobspec ограничивает работу запущенными заданиями.

С помощью disown вы можете закрыть терминал и запустить процесс на компьютере.

Я застрял в большом mv, поэтому я не мог остановить процесс, экран настройки и затем запустить его снова. Мне удалось выйти из сеанса ssh с запущенным процессом, выполнив следующие действия:

sSH [сервер]
команда
Ctrl + Z
б.Г.
disown [необязательный pid процесса, по умолчанию последний)
Результат

Шаг 3 приостанавливает текущий процесс (например, моя команда 'mv').
Шаг 4 переводит приостановленный процесс в фоновый режим и возобновляет его.
Шаг 5 позволяет вам отказаться от процесса. ** Чтобы получить список вакансий, просто введите jobs before.

** Относительно откровения (из руководства bash):

Есть две основные программы, которые вы можете использовать для поддержки программ и состояния терминала через несколько соединений SSH. Это screen (действующий, но, к сожалению, не поддерживаемый. Видимо сейчас активно развивается ) и tmux (новее, активно поддерживается). Byobu - это интерфейс, который может работать поверх этих систем и предоставлять дополнительную информацию о состоянии Ubuntu. В новых установках он будет использовать tmux в качестве бэкэнда, если у вас более старая установка byobu и существующий конфиг, он будет поддерживать предыдущий бэкэнд, будь то screen или tmux.

Byobu можно установить на компьютер, выполнив это на компьютере с Debian:

Используя yum, вы делаете

Также возможно установить byobu на другие дистрибутивы.

Использование byobu

Вы можете запустить byobu, запустив byobu на хост-машине после подключения с использованием ssh. Это даст вам оболочку, которая выглядит следующим образом:

Вы также можете использовать Byobu Terminal на машине с Ubuntu с опцией -X и легко получить идеально работающую byobu.

Использование:

Запустите byobu, набрав byobu .

Вы можете нажать F2, чтобы создать новое окно в текущем сеансе, F3-F4, чтобы переключаться между различными окнами.

Чтобы покинуть бёбу и держать его работающим (отсоединить), нажмите F6.

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

Вы также можете создавать различные сеансы byobu с помощью byobu -S session1 и так далее. И вы можете подключиться к любому из них, когда вы вернетесь.

Вы можете сделать гораздо больше, используя Byobu. Используй это! Некоторые окончательные руководства: здесь или здесь .

Вы не можете сделать это после запуска процесса, вам нужно настроить все, прежде чем запускать долго выполняемое задание.

Вы можете использовать Nohup , но современная мудрость предполагает, что вы используете экран или бёбу в качестве логина, чтобы вы могли отсоединиться и оставить все как есть.

Преимущество Screen заключается в том, что вы можете отсоединиться от одного компьютера и снова подключить его к другому, что удобно, если вы хотите проверить длительно работающие процессы, работающие после конца рабочего дня.

Есть разумное начало руководство к экрану здесь.

byob помещает простой в использовании интерфейс в верхней части экрана с меню и т. д. Это также текущая реализация экрана в более новой Ubuntu. F2 для запуска новой клеммы F3/F4 для переключения вперед и назад и F6 для отключения. Введите exit, чтобы окончательно завершить терминалы.

Для одного сценария Shell, который я выполняю в течение длительного периода времени, я войду в систему и запусту процесс в фоновом режиме, используя '&'.

Я вышел из системы и отключил сеанс SSH. Когда я регистрируюсь через некоторое время, сценарий все еще выполняется, что подтверждается непрерывным сбором данных из сценария.

Эй, пока я согласился, что экран - самый эффективный вариант. Вы можете использовать vncserver, а затем запустить процесс на нем.

Кроме того, если ваш единственный интерес заключается в том, чтобы запустить процесс и не нужно возвращать его к себе, и, что крайне важно, вы не знали, что вам нужно будет закрыть сеанс, и у вас уже запущен процесс, вам не повезет, если вы использовали Bash в качестве оболочки

Наконец, вызовите команду disown (с последующим идентификатором jobid . как с командой bg)

Это удалит родительско-дочерние отношения между вашей Командой Shell и процессом в фоновом режиме, предотвращая его отмирание после прекращения работы вашей Команды.

Вы должны проверить GNU Screen и посмотреть, поможет ли это вам. В зависимости от того, как вам нужно, чтобы ваше приложение работало в реальном времени, оно может вызвать больше проблем, чем решает, но, по крайней мере, это позволит вам возобновить сеанс, как будто вы никогда его не покидали.

Есть много других опций, например, разделенные экраны, а также все ярлыки полностью настраиваемые.

Самый простой ответ .

ctrl + Z приостановит запущенную программу

"BG" будет запускать его в фоновом режиме

Самый простой способ - запустить команду в фоновом режиме с помощью & . Тогда просто напиши:

В то время как все говорят, что нужно использовать disown (единственный вариант, который у вас есть после того, как вы уже запустили процесс), Nohup или даже запускать команду в screen , что полезно, если вы хотите увидеть все выходные данные команды . Я фанат screen .. Я до сих пор пробовал самые последние распространенные дистрибутивы Linux, и просто перевод задания в фоновый режим и выход из него не приводят к остановке всех запущенных процессов. Там должно быть глобальное урегулирование или что-то. Я пытаюсь сделать это на некоторых довольно старых системах (slackware 12), и мой тестовый скрипт продолжает работать, пока я не убью его вручную:

Хотя я согласен с тем, что screen будет наилучшим способом выполнить это, даже если мой сценарий будет записывать в файлы журналов или что-то еще .. Мне никогда не приходилось использовать disown -a или Nohup , если это не было полной паранойи. Может быть, кто-то может пролить свет на поведение bash по умолчанию? Может быть, некоторые системные администраторы изменяют настройки по умолчанию для больших оболочек, чтобы процессы своих пользователей не перегружали систему?

Мне часто приходилось сталкиваться с тем, что при обрыве соединения SSH-сессия закрывалась и все исполняемые в ней процессы прерывались. Иногда это приводило к потере многочасового труда. В этой статье я расскажу про инструмент, который поможет застраховать себя от подобных проблем. Кроме этого этот инструмент даёт нам возможность разделения экрана на области, с возможностью выполнять разные задачи в каждом из них.

В качестве SSH-клиента я использую Putty или его брата-близнеца Kitty. Оба этих инструмента вышли из одного проекта, но потом получили разное, независимое друг от друга, развитие. При использовании SSH-клиента самая большая проблема - это обрыв соединения. Если связь между клиентом и сервером отсутствует больше времени таймаута, то соединение на сервере принудительно завершает свою работу. Избежать этого можно увеличив время таймаута в настройках клиента. Но это не панацея. Более удобным способом, на мой взгляд, является использование утилиты TMUX.

При обрыве соединения tmux, и все процессы, запущенные из под него, продолжат работать в фоновом режиме, и при новом подключении можно будет вновь подключиться к tmux и продолжить работу. Я не буду описывать процесс установки этой утлиты. К тому же она доступна в большинстве репозиториев современных дистрибутивов Linux. Хочу рассказать только об одной особенности использования tmux.

Tmux работает следующим образом. После установления SSH-соединения с сервером, вы запускаете tmux, который в свою очередь запускает экземпляр шела (например bash) и далее вы работаете в нём как обычно. При обрыве соединения, вы вновь подключаетесь по SSH и подключаетесь к той сессии TMUX, которую запустили ранее. Все процессы, запущенные в ней, всё это время, будут работать как ни в чём не бывало. Но я часто ловил себя на том, что, подключаясь к серверу я забывал запустить tmux и работал в обычном окне терминала. Что собственно и приводило к нежелательным последствиям при отключении соединения. Чтобы этого избежать я добавил tmux в “автозагрузку”. Для этого я внёс кое-какие изменения в файл .bashrc.

Существует множество файлов, которые выполняются во время запуска сессии: .bashrc; .bash_profile; .profile и т.д.. В следующих статьях я напишу о нюансах их использования и чем они отличаются.

Тут видно, что значение переменной $TMUX = /tmp/tmux-1000/default,32666,7 . Таким образом, можно при запуске проверять, если мы уже внутри TMUX, то не нужно пытаться запускать его повторно. Я сделал это так. Вместо просто запуска TMUX вставил условие.

В Linux есть такая замечательная штука как test. Если набрать man test, то мы увидим, что означает –z:

В нашем примере, в случае если переменная пуста, то будет возвращено значение TRUE. Таким образом будет проведена проверка и TMUX запуститься только в том случае, если переменная $TMUX пуста (то есть TMUX еще не был запущен).

В результате мы добиваемся своей цели. При подключении к серверу и входе в систему TMUX будет запускаться автоматически.

Этичный хакинг и тестирование на проникновение, информационная безопасность

Туннелирование с SSH. Открытие графической программы, расположенной на удалённом компьютере, по SSH

Для следующего фокуса нужно два компьютера с системой Linux. К сожалению, даже Cygwin с этим трюком не справляется. Причём оба Linux'а должны быть с графическим пользовательским интерфейсом.

Среди всего прочего, что происходит когда устанавливается соединение с удалённым хостом через SSH, это создание зашифрованного туннеля, который образуется между локальной и удалённой системами. Обычно, этот туннель используется для того, чтобы набранные на локальной машине команды безопасно были переданы удалённой машине, а результат, также безопасно, прислан обратно.

В добавок к этой базовой функции, протокол SSH позволяет переправлять большинство типов трафика по зашифрованному туннелю, создавая некого рода VPN (виртуальную частную сеть) между локальной и удалённой системами.

Пожалуй самая часто используемая из этих функций — это возможность транслировать трафик систем X Window. На системе с запущенным X сервером (это машины, которые имеют графический пользовательский интерфейс) возможно запустить программу X клиента (графическое приложение) на удалённой системе и видеть результаты её работы на локальной системе. Сделать это просто. Например, я хочу подключиться к удалённому хосту АДРЕСАТ и на нём я хочу запустить программу КОМАНДА. При этом видеть графический вывод этой программы я смогу на локальном компьютере. Делается это так:

Т.е. SSH запускается с ключом -X. А затем просто запускается программа.

Я нахожусь в Arch Linux. Я успешно логинюсь к удалённому компьютеру по SSH. После этого я запустил программу recon-ng. Этой программы даже нет на Arch Linux, но она точно есть в Kali Linux, к которой я и подключился. Результат работы этой программы я могу видеть на экране так, будто бы программа запущена локально. Но, повторюсь, я хочу, чтобы вы это поняли, запущенной программы recon-ng на локальном компьютере нет. Если я захочу сохранить результат работы recon-ng (или любой другой программы, открытой таким образом), то окажется, что она работает в окружении удалённого компьютера, видит его файловую систему и т. д. Это удобно, когда вы хотите настроить удалённый компьютер используя графический интерфейс.

Использование SSH в качестве прокси для доступа к локальным ресурсам удалённого компьютера

Подробности смотрите в разделах:

Установка VPN через SSH

В SSH есть встроенные возможности туннелирования — программа автоматизирует создание туннельных интерфейсов на сервере и клиенте, подробности в этом разделе.

Как редактировать файл на другом компьютере через ssh

Когда нужно отредактировать файл, размещённый на удалённом хосте, было бы здорово, если бы можно было отредактировать его локально так, будто бы это локальный файл. Конечно, можно поднять NFS через ssh туннель для достижения этого, но это было бы слишком излишним для использования один раз. Отсюда вопрос: есть ли способ отредактировать через ssh размещённый на другом компьютере файл?

Если вы хотите отредактировать удалённый файл через ssh с использованием vim, вы можете сделать так.

Реальный пример команды:

Обратите внимание на двойной слеш "/" для каталога root на удалённом хосте. Вышеприведённая команда vim откроет файл, размещённый на удалённом хосте для редактирования. За сценой, vim использует scp для получения запрошенного файла с удалённого хоста, размещает файл в /tmp и, наконец, открывает его для редактирования.

Когда вы попытаетесь сохранить изменения в файле, изменения, в первую очередь, будут применены к локальной копии в /tmp, которая затем выгрузиться через scp на удалённый хост.

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

Внимание, этот фокус не работает в Cygwin — только в настоящем Linux.

Как сравнить файлы на удалённом компьютере (выполнить команду diff) через SSH

diff — это утилита командной строки, которая сравнивает содержимое двух файлов (или директорий) и построчно показывает в чём они различаются. Очень просто пользоваться diff, когда оба файла размещены на локальном хосте. А как быть если (один или оба) входных файла размещены на удалённом хосте? Вы можете использовать SSH для сравнения этих файлов по сети. Здесь как применить команду diff к удалённым файлам по SSH.

Утилита diff может принимать один операнд в форме stdin (стандартного ввода) (представляется как "-"), и вы можете использовать эту особенность для достижения цели по применению diff через SSH следующим образом.

ssh ПОЛЬЗОВАТЕЛЬ@УДАЛЁННЫЙ_ХОСТ "cat remote_file.txt" | diff — local_file.txt

Вышеприведённая команда запросит у вас SSH пароль для удалённого хоста. После корректного ввода пароля, команда прочитает содержимое удалённого файла через SSH а затем передаст его по трубе в утилиту diff для сравнения с локальным файлом.

Другой метод для сравнения содержимого файла по SSH — это ясное использование перенаправления ввода. Чтобы использовать этот второй метод вы должны для начала включить беспроводной вход по ssh в удалённый хост(ы). Подразумевая что это готово, вы можете делать следующее:

Для сравнения (diff) локального файла и удалённого файла:

Для сравнения (diff) двух удалённых файлов:

Обратите внимание, что последние команды потерпят неудачу, если удалённые хосты потребуют от вас ввода пароля SSH для доступа. Также запомните, что вышеприведённое перенаправление ввода не поддерживается шеллом sh. Используйте шелл bash или что-нибудь совместимое.

Как настроить VNC через ssh

По своей природе VNC — это не безопасный протокол. Хорошо известнен риск безопасности VNC: соединение с сервером VNC осуществляет по сети через не зашифрованный канал. Т.е. кто угодно может стащить установленную VNC сессию. Для защиты от VNC сниффинга, вам следует попробовать дополнительные внеполосные механизмы шифрования, под или над соединением VNC.

Один из таких механизмов — это настройка VNC сессии через SSH туннель. В этом уроке я опишу как настроить VNC через SSH на Linux.

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

Чтобы создать SSH туннель к удалённому хосту, где запущен VNC сервер, удалённый хост должен также иметь запущенный SSH. Поэтому для начала установите сервер OpenSSH на удалённый хости (как это сделать рассказано в первой части).

Следующий шаг — это создание SSH туннеля с локального хоста на удалённый хост. Чтобы это сделать, запустите следующую команду. Здесь 5900 — это номер порта, который прослушивает удалённый VNC сервер.

После введение SSH пароля и успешного входа, будет установлен SSH туннель между 127.0.0.1:5900 и remote_host:5900.

Теперь вы можете продолжать и запустить клиент VNC на локальном хосте. В вашем VNC клиенте соединитесь к 127.0.0.1:5900 вместо удалённого VNC сервера. Тогда трафик VNC будет перенаправляться через SSH туннель между вами и удалённым сервером VNC и, следовательно, он будет обезопасен от перехвата пакетов.

Как включить форвардинг (пересылку) X11 с использованием ssh

Пересылка X11 — это механизм, который позволяет графическому интерфейсу программ X11, запущенных на удалённом сервере Linux, быть отображёнными на локальной клиентской машине. За сценой, вывод X11 удалённо запущенной программы, санкционирован для отправки на локалхост через соединение X11 между клиентом и удалённым сервером. SSH имеет опции для безопасного туннелирования таких X11 соединений так, что сессия пересылки X11 получается зашифрована и инкапсулирована. Если вы хотите настроить форвардинг X11 через SSH, то ознакомьтесь с этой инструкцией.

Для пересылки X11, не требуется, чтобы на удалённый серверный хост имел полную установленную систему X11. Тем не менее на серверном хосте нужен как минимум установленный xauth. xauth — это утилита, которая поддерживает конфигурацию Xauthority, используемую сервером и клиентом для аутентификации X11 сессий. Для установки xauth, сделайте следующее на удалённом сервере:

Для Debian, Linux Mint, Ubuntu, Kali Linux и их производных:

На Arch Linux и производных:

Затем включите перенаправление X11 в sshd, добавив в файл /etc/ssh/sshd_config директиву:

Чтобы изменения вступили в силу, перезапустите службу sshd.

Вышеприведённая настройка включит пересылку X11 на всей системе серверного хоста. Если вместо этого вы хотите включить пересылку X11 на основе индивидуального пользователя, вы можете использовать специфичный для каждого пользователя конфигурационный файл ssh (например, $HOME/.ssh/config). Таким образом, вы можете использовать пересылку X11 только когда вы запускаете ssh в конкретном пользовательском аккаунте.

В отличие от удалённого серверного хоста, машине с локальным клиентом нужна установленная система X11 для отображения удалённой запущенной программы X11. Если всё так, то в этом случае вы можете открыть ssh соединения из локальной машины на удалённый сервер следующим образом.

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

Сохранение запущенной команды после закрытия SSH

Если в SSH вы запустили команду, то после отключения от SSH, эта команда будет сразу же остановлена. Даже если вы перевели её в фон с помощью &:

Сетевая файловая система SSHFS

Имеется более универсальный вариант, который является также весьма простым. Этот способ требует установки двух дополнительных пакетов:

sshfs — позволяет монтировать удалённую файловую систему используя SFTP. Говоря простым языком, файлы удалённого сервера будут как будто бы частью вашей файловой системы. Следовательно, любы приложения смогут с ними работать.
fuse — FUSE (Filesystem in Userspace), то есть файловая система в пространстве пользователя. Является интерфейсом к файловой системе, позволяет монтировать файловую систему с правами обычного пользователя.

Установка необходимых пакетов в Debian, Linux Mint, Ubuntu, Kali Linux и их производных:

Установка необходимых пакетов в Arch Linux, BlackArch и их производных:

После установки пакетов, создайте папку, куда будет монтироваться удалённая файловая система — это должна быть папка, к которой у вас есть доступ без повышенных привилегий, к примеру:

Для монтирования нужно запустить команду вида:

Если нужно указать порт, то используйте опцию -p в конце команды.

К примеру, мне нужно смонтировать директорию /root хоста 185.117.153.79 где я хочу выполнить вход от пользователя root; при этом на локальной системе я хочу выполнить монтирование в папку Downloads/ssh; на удалённой системе SSH работает на порту 2222, тогда моя команда будет такой:

Теперь файлы папки /root хоста 185.117.153.79 будут доступны в Downloads/ssh на локальном компьютере. Обратите внимание, что команда sshfs не потребовала sudo.

Для автоматизации, можно настроить вход на SSH по ключу (без пароля), и сохранить команду монтирования с sshfs в файл/скрипт для быстрого подключения.

Связанные статьи:

факультете информационной безопасности от GeekBrains? Комплексная годовая программа практического обучения с охватом всех основных тем, а также с дополнительными курсами в подарок. По итогам обучения выдаётся свидетельство установленного образца и сертификат. По этой ссылке специальная скидка на любые факультеты и курсы!

Я работаю над Linux-машиной через SSH (Putty). Мне нужно оставить процесс, работающий в течение ночи, поэтому я подумал, что могу сделать это, запустив процесс в фоновом режиме (с амперсандом в конце команды) и перенаправляя stdout в файл. К моему удивлению, это не работает. Как только я закрою окно Putty, процесс будет остановлен.

Как я могу предотвратить это?

Вы можете использовать nohup command > /dev/null 2>&1 & для запуска в фоновом режиме без создания вывода stdout или stderr (без файла nohup.out )

Что делать, если мне нужно предоставить какой-то вклад? Например, у меня есть долгосрочный скрипт, который мне нужно запустить в фоновом режиме, но сначала он запрашивает мой пароль FTP. nohup не помогает в этом случае. Есть ли способ возиться с Ctrl+Z / bg ?

Поскольку я ленив и плохо запоминаю загадочные последовательности символов, я написал это , основываясь на том, что сказал @KCD, и много использовал его.

Это не работает на моей стороне, так как это не защищает программу от получения SIGHUP при закрытии ctty. У меня есть программа, которая никогда не должна получать SIGHUP. nohup не работает, так как он не предотвращает SIGHUP, он просто по умолчанию игнорирует его, что не обязательно превалирует. Поскольку у меня нет ни screen ни tmux ни at ни схожего, мне нужен способ на уровне оболочки, чтобы точно отсоединить программу от ctty. Единственным способом, который я нашел, был хак, чтобы запустить программу с помощью ssh -T remote '(program&)&' что делает невозможным фоновую программу в интерактивном ssh сеансе.

Я бы рекомендовал использовать экран GNU. Это позволяет вам отключиться от сервера, пока все ваши процессы продолжают работать. Я не знаю, как я жил без него, прежде чем знал, что он существует.

Это одна из величайших программ, которые я когда-либо использовал. Шутки в сторону. У меня он работает на BSD-боксе, в который я запускаю ssh из ВЕЗДЕ, и могу просто повторно присоединить его к моему экрану и иметь все свои терминалы, где я делаю все виды вещей.

Я могу засвидетельствовать это. Экран - отличное приложение. Способность повторно прикрепить удивительна и экономит много потенциально потерянной работы.

Я даже использую его на локальных машинах и присоединяю несколько xterms к одному сеансу экрана (screen -x). Таким образом, я могу открыть много окон в своем сеансе экрана и свободно переключать свои различные xterms из окна в окно.

Зависит от того, нужно ли вам повторно подключаться к фоновому приложению или нет. Если вы это сделаете, то, да, экран - единственный способ летать. Однако, если это огонь и забыл, то nohup отвечает всем требованиям так же хорошо, если не лучше.

Существует также 'dtach', который реализует только механизм отсоединения экрана, однако это немного сложнее в использовании, но дает контроль над файлом сокета, который создается для отдельного процесса. Я бы порекомендовал использовать dtach, если бы это был неинтерактивный сценарий, требующий удаленного запуска процессов. В противном случае просто используйте экран, это проще.

Когда сеанс закрыт, процесс получает сигнал SIGHUP, который, по-видимому, не захватывает. Вы можете использовать команду nohup при запуске процесса или встроенной команды bash disown -h после запуска процесса, чтобы это не произошло:

демон? поЬир? SCREEN? (tmux ftw, экран неактивен; -)

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

Взрыв! Выполнено:-) Я использовал это бесчисленное количество раз для всех типов приложений и многих старых машин. Вы можете комбинировать с переадресацией и еще не открывать частный канал между вами и процессом.

Создать как coproc.sh:

И вот ты иди, породишь все. sleep 1 вместо : , потому что он немного яркий, и я получаю ошибку "файл занят" - никогда не происходит, если выполняется реальная команда (например, command true )

Это работает на каждой отдельной оболочке, которую я когда-либо пробовал, включая busybox/etc (initramfs). Я никогда не видел, чтобы это делалось раньше, я самостоятельно обнаружил это, когда подталкивал, кто знал, что источник может принять аргументы? Но он часто выступает в качестве более управляемой формы eval, если есть такая вещь.

Неважно, насколько хорош ваш ответ, иногда кому-то на SO это не понравится и он понизит голос. Лучше не слишком беспокоиться об этом.

Этот метод не работает при попытке запустить работу программно через ssh, например, '$ ssh myhost "((exec sleep 30) &)"'

@ tbc0 уверен, что делает; Ctrl ^ C ssh-клиент после его зависания, затем войдите в систему на компьютере . вы увидите, что команда sleep 30 все еще выполняется. я не уверен, почему ssh не освобождает (хотя я предполагаю, что процесс сна все еще содержит ссылку на pty или аналог ssh), но независимо от того, на команду сна не влияют никакие отправленные сигналы (такие как Ctrl ^ В) и сохранится после закрытия ssh.

@anthonyrisinger хорошо, это работает. Я думаю, что это чище: ssh myhost 'sleep 500 >&- 2>&- TMTOWTDI;)

Это замечательно. единственное решение, которое на самом деле работает в busybox. это заслуживает большего количества голосов

Замените имя своего процесса на blah!

nohup перенаправляет stdout и stderr на nohup.out (или nohup.out и nohup.err в зависимости от версии), поэтому, если вы не запускаете несколько команд, это необязательно.

Лично мне нравится команда "пакет".

Это заносит его на задний план, а затем отправляет вам результаты. Это часть cron.

Как отмечали другие, для запуска процесса в фоновом режиме, чтобы вы могли отключиться от сеанса SSH, вам необходимо, чтобы фоновый процесс должным образом отключился от своего управляющего терминала, - это псевдо-tty, что сеанс SSH используется.

Вы можете найти информацию о процессах демонализации в таких книгах, как "Расширенная сетевая программа, Vol 1, 3 Edn" или Rochkind "Стивенс Стивенс".

Недавно (за последние пару лет) пришлось иметь дело с непоколебимой программой, которая не демонанизировала себя должным образом. Я в конечном итоге столкнулся с этим, создав общую программу демонатизации - похожую на nohup, но с большим количеством доступных элементов управления.

Двойная тире является необязательной для систем, не использующих функцию GNU getopt(); необходимо (или вы должны указать POSIXLY_CORRECT в среде) на Linux и т.д. Поскольку двунаправленная работа работает везде, лучше всего использовать ее.

Вы все равно можете связаться со мной (имя первого имени точки в gmail dot com), если вы хотите источник для daemonize .

Однако код теперь (наконец) доступен на GitHub в моем SOQ (Stack Overflow Questions) в качестве файла daemonize-1.10.tgz в packages подкаталог.

Читайте также: