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

Никак, твой процесс уже сдох.

Никак, твой процесс уже сдох.

Не путай фоновые процессы и демоны.

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

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

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

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

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

Как

Попробуй reptyr.

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

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

Ой наврал, CTRL+Z - это SIGSTOP, но не суть, это близко =)

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

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

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

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

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

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

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

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

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

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

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

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

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