Куди йде вихід із програми, запущений у вікні диспетчера?

10

Якщо ви запускаєте програму з терміналу, ви можете бачити вихід у stdout та stderr, але якщо програма запущена з вікна менеджера, куди зазвичай йде вихід у ці файли? До / dev / null?

xorg logs stdout

— Август Карлстром
джерело

1

Пропозиція: використовуйте ps fauxдля перевірки, які tty / pts пов'язані з процесом. якщо немає або "?" вона, ймовірно, втрачається в порожнечі. (це лише ідея, я можу помилятися)

— mveroone

@Kwaio: Значення є знаком питання (?), Тому, як ви кажете, воно, ймовірно, втрачається в порожнечі.

— Серпень Карлстром

2

Якщо ви запустили свою графічну оболонку з gdm або kdm, вихід можна знайти в~/.xsession-errors

— Шадур,

8

Вихід програми, запущений з менеджера вікон, переходить на те саме місце, що і вихід з самого менеджера вікон. (Якщо додаток не перенаправляє його, але типові програми GUI цього не роблять.)

Ви можете дізнатися, куди йде вихід WM, подивившись, що він відкритий у дескрипторі файлів 1 (стандартний вихід) та дескрипторі файлу 2 (стандартна помилка); зазвичай обидва будуть переходити в один і той же файл. Дізнайтеся ідентифікатор процесу вашого менеджера вікон (спробуйте, наприклад, pgrep metacityабо pidof metacityякщо Metacity - це ваш менеджер вікон - якщо ви не знаєте ім'я процесу для свого менеджера вікон, подивіться корінь одного з дерев процесів, про які повідомляє ps fабо pstree). Припустимо, ідентифікатор процесу вашого менеджера вікон становить 1234, запустіть

lsof -p1234

і шукайте рядки, що відповідають дескрипторам файлів 1 і 2, або

або

ls -l /proc/1234/fd

Ви можете автоматизувати фільтрацію відповідних дескрипторів файлів:

lsof -p1234 | awk '$4 ~ /^[12][^0-9]/'
ls -l /proc/1234/fd/[12]

(Примітка: всі команди, наведені вище, призначені для Linux. pgrepПоширений серед інших уніцій, і lsofїх можна встановити майже в будь-якому місці; psпараметри та /procвміст у різних одиницях різні.)

У звичайній ситуації, коли ви виконуєте команди з оболонки, що працює в емуляторі терміналу (xterm, konsole, gnome-terminal тощо), але не використовується у екрані чи tmux), ви можете легко перевірити, де виходить емулятор терміналу відбувається, оскільки емулятор терміналу є батьківським процесом вашої оболонки. Це не працює, якщо емулятор терміналу працює з додатковими привілеями, що трапляється в деяких системах, щоб емулятор термінала міг записуватись до списку користувачів, що увійшли (utmp).

lsof -p$PPID
ls -l /proc/$PPID/fd

Багато дистрибутивів направляють вихід X сесії на ~/.xsession-errors.

— Жил "ТАК - перестань бути злим"
джерело

У моєму випадку дочірня ієрархія, що починається з WM, є blackbox <- lightdm <- lightdm <- init, і всі ttys мають значення "?". Я здогадуюсь тоді, що вихід нікуди.

— Серпень Карлстром

@AugustKarlstrom Тоді pidof blackboxабо pgrep blackboxотримати PID вікна-менеджера, або безпосередньо lsof -p$(pidof blackbox). Тити не мають до цього нічого спільного.

— Жил "ТАК - перестань бути злим"

1

Ах, звичайно. Команда ls -l /proc/<blackbox-id>/fdповідомляє мені, що stdout переходить до /dev/nullі stderr ~/.xsession-errors.

— Серпень Карлстром

1

Менеджер вікон - це дитина-сервер X-сервера, тому він і його вихідні діти переходять на те саме місце, що і X-сервер.

Якщо ви єдиний користувач і входите графічно, деякі системи витісняють екземпляр сервера X з консолі виводу, тобто ви можете переключитися на цей VT і переглянути його. Анекдотично, розташування зазвичай alt-ctrl-f1є вихідною консоллю для екземпляра X і alt-ctrl-f7є дисплеєм X, але ви можете перевірити стільки, скільки зможете знайти. Перші 6 зазвичай нереєнтовані логіни, але можливі більше таких, які не роблять і будуть видані порожніми або з трубопровідним висновком. На деяких з них може бути вихід з init, не плутайте це з результатом з X. На мій досвід, X і діти завжди балакають значну кількість попереджень і повідомлень (про відсутні шрифти, амортизовані дзвінки тощо).

Якщо ви не входите через графічний інтерфейс, це буде будь-який VT, з якого ви починали X, що є проблемою, оскільки ви не побачите цього, поки не вийдете. Я вважаю, що при вході в графічний інтерфейс XDM (графічний логін) працює як привілейований процес, тобто він може передавати вихід /dev/tty7. Ви також можете ( startx 1>&2> /dev/tty7), якщо у вас є права привілеїв суперпользователя.

— золотинки
джерело

1

У випадку startxабо xinitбезпосередньо, ви завжди можете налаштувати ~/.xinitrcпереадресацію за потребою перед тим, як робити це execна потрібному менеджері вікон. Сам я ніколи не пропускав такого виду. Якщо мене цікавить, що виробляє додаток GUI, я запускаю його з терміналу. Але насправді це може бути корисним, тому я перенаправив stdout та stderr ~/.xinitrcна ~/.xinitrc.out.

— Мирослав Кошкар

0

Якщо прийняти, що зазвичай одна програма запускає іншу, роблячи серію, man 2 forkа man 2 execveпотім у цьому процесі дескриптори файлів за замовчуванням залишаються відкритими.

Отже, відповідь полягає в тому, що зазвичай вихід / помилка йде там, де вихід / помилка батьківського процесу вказував на час розщеплення (якщо тільки батьківська програма звичайно не переспрямовує). Я думаю, ви не можете вимагати нічого більш конкретного, якщо ми точно не знаємо ім'я батьківської програми. Процес керування вікнами рідко залучається безпосередньо до запуску інших програм.

Наприклад, у моєму випадку

xmonadпочнеться натискання клавіш Ctrl + P (обробляється менеджером вікон)dmenu_run
dmenu_runбуде обробляти мій внесок і запускати якусь програму (наприклад, xkill)

Вихід піде на /dev/tty1тому, що

xkill було розпочато dmenu_run
dmenu_run було розпочато xmonad
xmonad було розпочато X
X було розпочато startx
startx був запущений мною вручну з першої віртуальної консолі /dev/tty1

Для ознайомлення, якщо ви хочете знайти, куди йде вихід / помилка, або краще сказати, які дескриптори файлів відкриті для певного процесу (з відомим PID), зробіть

$ lsof -p PID

— Мирослав Кошкар
джерело