LINUX.ORG.RU

Подключить терминал к фоновому процессу

 , , ,


0

2

Всем привет. Вопрос новичка. Дистрибутив debian 10. Запустил фоновый процесс: command &, потом закрыл терминал. Как в новом открытом терминале вернуть вывод процесса на экран, то есть подключить stdout процесса к текущей консоли.

Ответ на: комментарий от Binkledum

ps aux | grep command в новом терминале показывает, что живет.

andr_ey ()
Ответ на: комментарий от Binkledum

Не могли бы вы пояснить, нашел много путающих определений демона и фонового процесса.. command & - это фоновый процесс, так? а это тот, который прописывается, как unit в systemd?

andr_ey ()

Вариант первый, вернуться в прошлое и запустить его через nohup или в сессии мультиплексора.

Вариант второй, поискать на SO или в гугле «How to view the output of a running process in another session».

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от Binkledum

Процесс узнаёт о закрытии терминала по сигналу SIGHUP. По умолчанию обработчик этого сигнала завершает процесс. Но если программа переопределит обработчик SIGHUP, то после закрытия терминала вполне себе успешно останется запущенной.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от andr_ey

Юниты в systemd обычно (или всегда? я хз, я не очень знаком с этими новомодными штуками вроде systemd) являются демонами, но само понятие демона/демонизации никакого отношения к systemd не имеет. Если кратко: демон - процесс, отвязанный от терминала (нет связанного с ним tty), у которого parent - PID 1, CWD - / и вроде ещё пара условий. Есть несколько способов сделать демона, например всё вышеперечисленное сделать руками, сделать double fork, прибить родителя и тд, есть библиотечная функция, которая это делает (man 3 daemon). Если делать не из кода, а из консоли, вроде была одноимённая утилита daemon.

Теперь про background processes: в большинстве шеллов, в частности, в bash, реализована концепция фоновых задач, то есть задач, которые не «мешают» текущей сессии, увидеть список задач можно с помощью встроенной команды (не программы, это именно встроенная команда) jobs, задачу можно отправить в бэкграунд либо при запуске (&), либо с помощью сигнала (номер сигнала не помню, но в шелле это обычно хоткей CTRL+Z), при этом у фонового процесса помимо PID появляется ещё один идентификатор - его номер в списке jobs. По этому номеру его можно прибить, или вызвать его в форграунд (fg). Но все фоновые задачи остаются привязанными к текущей сессии и являются дочерними процессами текущего процесса шелла. При дефолтных настройках при прибивании сессии они все дохнут тоже, вроде бы (не во всех шеллах) можно натюнить оболочку так, что они не будут прибиваться.

Binkledum ()
Ответ на: комментарий от i-rinat

Да, твоя правда, про этот момент я забыл. Я там ещё портянку ТСу накидал, поправь, если где я ошибся, плиз.

Binkledum ()

Запускай command в screen или tmux.

anonymous ()

Спасибо всем за ответы, но для ясности еще раз.

  1. Я понимаю, что в рамках текущей сессии с терминалом мы можем отправить задачу в back (хотя ping не отправляется, хз почему). И в этой же сессии получить доступ к задачам (группе процессов?), используя jobs, fg, bg.
  2. Но после запуска command & задача уходит в фон (допустим непрерывный вывод в консоль некого значения). Когда мы закрываем терминал, то процесс висит в воздухе (ps aux } grep command), непривязанный к терминалу. Куда он тогда выводит данные?
  3. Если не озаботиться использованием мультиплексоров сессии, а просто по дефолту закрыть терминал, то вывода данных этого процесса мы уже не увидим?
  4. Этот, повисший процесс виден в ps aux наряду со всеми демонами, например docker, но вы говорите, что это не демон?
andr_ey ()
Ответ на: комментарий от andr_ey

Куда он тогда выводит данные?

В никуда. Как в /dev/null.

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

Без чего-то вроде reptyr (уже упоминали выше) или ручного подключения с помощью gdb с переоткрытием stdout/stderr вывод увидеть не выйдет.

Этот, повисший процесс виден в ps aux наряду со всеми демонами, например docker, но вы говорите, что это не демон?

Все демоны – фоновые процессы, но не все фоновые процессы – демоны.

xaizek ★★★★★ ()
Ответ на: комментарий от andr_ey

Куда он тогда выводит данные?

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

bigbit ★★★★★ ()
Ответ на: комментарий от andr_ey

Считай так, демон это программа заточенная для работы в фоновом И автоматическом режиме.

torvn77 ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.