Перенаправити STDERR / STDOUT процесу ПІСЛЯ його запуску, використовуючи командний рядок?

У оболонці ви можете зробити перенаправлення > <тощо, але як щодо ПІСЛЯ запуску програми?

Ось як я прийшов задати це питання, програма, що працює на тлі мого терміналу, продовжує виводити набридливий текст. Це важливий процес, тому я повинен відкрити ще одну оболонку, щоб уникнути тексту. Я хотів би мати можливість >/dev/nullчи якесь інше перенаправлення, щоб я міг продовжувати працювати в одній оболонці.

Окрім закриття та повторного відкриття ваших tty (тобто вихід із системи та повторне ввімкнення, що також може припинити деякі фонові процеси в процесі), у вас залишився лише один вибір:

• приєднайте до відповідного процесу за допомогою gdb та запустіть:
  • p dup2 (відкрити ("/ dev / null", 0), 1)
  • p dup2 (відкрити ("/ dev / null", 0), 2)
  • відриватися
  • кинути

наприклад:

$ tail -f /var/log/lastlog &
[1] 5636

$ ls -l /proc/5636/fd
total 0
lrwx------ 1 myuser myuser 64 Feb 27 07:36 0 -> /dev/pts/0
lrwx------ 1 myuser myuser 64 Feb 27 07:36 1 -> /dev/pts/0
lrwx------ 1 myuser myuser 64 Feb 27 07:36 2 -> /dev/pts/0
lr-x------ 1 myuser myuser 64 Feb 27 07:36 3 -> /var/log/lastlog

$ gdb -p 5636
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Attaching to process 5636
Reading symbols from /usr/bin/tail...(no debugging symbols found)...done.
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f3c8f5a66e0 (LWP 5636)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2

(no debugging symbols found)
0x00007f3c8eec7b50 in nanosleep () from /lib/libc.so.6

(gdb) p dup2(open("/dev/null",0),1)
[Switching to Thread 0x7f3c8f5a66e0 (LWP 5636)]
$1 = 1

(gdb) p dup2(open("/dev/null",0),2)
$2 = 2

(gdb) detach
Detaching from program: /usr/bin/tail, process 5636

(gdb) quit

$ ls -l /proc/5636/fd
total 0
lrwx------ 1 myuser myuser 64 Feb 27 07:36 0 -> /dev/pts/0
lrwx------ 1 myuser myuser 64 Feb 27 07:36 1 -> /dev/null
lrwx------ 1 myuser myuser 64 Feb 27 07:36 2 -> /dev/null
lr-x------ 1 myuser myuser 64 Feb 27 07:36 3 -> /var/log/lastlog
lr-x------ 1 myuser myuser 64 Feb 27 07:36 4 -> /dev/null
lr-x------ 1 myuser myuser 64 Feb 27 07:36 5 -> /dev/null

Ви також можете врахувати:

• використання screen; на екрані передбачено кілька віртуальних TTY, з якими ви можете перемикатися між не потрібно відкривати нові сеанси SSH / telnet / тощо
• використання nohup; це дозволяє закрити і повторно відкрити сеанс, не втрачаючи фонових процесів у ... процесі.

Це зробить:

strace -ewrite -p $PID

Це не так чисто (показує рядки типу write(#,<text you want to see>):), але працює!

Можливо, вам також не подобається факт скорочення аргументів. Для контролю використовуйте -sпараметр, який встановлює максимальну довжину відображуваних рядків.

Він ловить усі потоки, тому ви можете хоч якось відфільтрувати:

strace -ewrite -p $PID 2>&1 | grep "write(1" 

показує лише дескриптор 1 викликів. 2>&1є перенаправлення STDERR на STDOUT, як straceпише за STDERR за замовчуванням.

викриваючи відмінні дослідження влади (та інших):

створити наступні два файли в одному каталозі, щось на вашому шляху, скажімо, $ HOME / bin:

silent.gdb, що містить (з відповіді власника):

p dup2(open("/dev/null",0),1)
p dup2(open("/dev/null",0),2)
detach
quit

і тиша, що містить:

#!/bin/sh
if [ "$0" -a "$1" ]; then
 gdb -p $1 -x $0.gdb
else
 echo Must specify PID of process to silence >&2
fi

chmod +x ~/bin/silence  # make the script executable

Тепер, наступного разу, коли ви забудете переспрямувати firefox, наприклад, і ваш термінал почне забиватися неминучим "(firefox-bin: 5117): Gdk-ПОПЕРЕДЖЕННЯ **: зіткнення XID, проблеми вперед":

ps  # look for process xulrunner-stub (in this case we saw the PID in the error above)
silence 5117  # run the script, using PID we found

Ви також можете перенаправити вихід gdb на / dev / null, якщо ви не хочете його бачити.

Перенаправлення виводу з запущеного процесу на інший термінал, файл або екран:

tty
ls -l /proc/20818/fd
gdb -p 20818

Всередині gdb :

p close(1)
p open("/dev/pts/4", 1)
p close(2)
p open("/tmp/myerrlog", 1)
q

Від'єднайте запущений процес від терміналу bash :

[Ctrl+z]
bg %1 && disown %1
[Ctrl+d]

Пояснення:

20818 - лише приклад запущеного процесу pid
p - результат друку команди gdb
close (1) - закрити стандартний висновок
/ dev / pts / 4 - термінал для запису, щоб
закрити (2) - закрити вихід помилки
/ tmp / myerrlog - файл до запишіть у
q - вийдіть з gdb
bg% 1 - запустіть стоп-завдання 1 на тлі
відключення% 1 - від'єднайте завдання 1 від терміналу

Це не пряма відповідь на ваше запитання, але це техніка, яку я вважаю корисною протягом останніх кількох днів: запустіть початкову команду за допомогою "екрана", а потім від'єднайте.

це частина сценарію bash на основі попередніх відповідей, що файл журналу переспрямування під час виконання відкритого процесу, використовується як постскрипт у logrotateпроцесі

#!/bin/bash

pid=$(cat /var/run/app/app.pid)
logFile="/var/log/app.log"

reloadLog()
{
    if [ "$pid" = "" ]; then
        echo "invalid PID"
    else
        gdb -p $pid >/dev/null 2>&1 <<LOADLOG
p close(1)
p open("$logFile", 1)
p close(2)
p open("$logFile", 1)
q
LOADLOG
        LOG_FILE=$(ls /proc/${pid}/fd -l | fgrep " 1 -> " | awk '{print $11}')
        echo "log file set to $LOG_FILE"
    fi
}

reloadLog

Dupx - проста утиліта * nix для переадресації стандартного виводу / вводу / помилки вже запущеного процесу.

https://www.isi.edu/~yuri/dupx/

Ви можете використовувати reredirect ( https://github.com/jerome-pouiller/reredirect/ ).

Тип

reredirect -m FILE PID

а результати (стандартні та помилки) будуть записані у ФАЙЛ.

перенаправлення README також пояснює, як відновити початковий стан процесу, як перенаправити на іншу команду або перенаправити лише stdout або stderr.

reredirectтакож надайте сценарій, який називається, relinkщо дозволяє перенаправляти на поточний термінал:

relink PID
relink PID | grep usefull_content

(Схоже, перенаправлення має ті ж функції, що і Dupx, описане в іншій відповіді, але це не залежить від Gdb).