Если вы запускаете приложение из терминала, вы можете видеть вывод в stdout и stderr, но если приложение запускается из оконного менеджера, куда обычно выводятся эти файлы? В / dev / null?
~/.xsession-errors
Если вы запускаете приложение из терминала, вы можете видеть вывод в stdout и stderr, но если приложение запускается из оконного менеджера, куда обычно выводятся эти файлы? В / dev / null?
~/.xsession-errors
Ответы:
Вывод приложения, запущенного из оконного менеджера, происходит в том же месте, что и вывод самого оконного менеджера. (Если приложение не перенаправляет его, но типичные приложения с графическим интерфейсом этого не делают.)
Вы можете узнать, куда выводится 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-терминал и т. Д., Но не при использовании через screen или tmux), вы можете легко проверить, где вывод эмулятора терминала идет, так как эмулятор терминала является родительским процессом вашей оболочки. Это не работает, если эмулятор терминала работает с дополнительными привилегиями, что происходит в некоторых системах, чтобы эмулятор терминала мог записывать в список зарегистрированных пользователей (utmp).
lsof -p$PPID
ls -l /proc/$PPID/fd
Многие дистрибутивы направляют вывод сеанса X на ~/.xsession-errors
.
pidof blackbox
либо pgrep blackbox
получить PID оконного менеджера, либо напрямую lsof -p$(pidof blackbox)
. Ttys не имеет ничего общего с этим.
ls -l /proc/<blackbox-id>/fd
сообщает мне, что stdout идет /dev/null
и stderr идет ~/.xsession-errors
.
Диспетчер окон является дочерним по отношению к X-серверу, поэтому он и его дочерние выходные данные находятся в том же месте, что и X-сервер.
Если вы являетесь единственным пользователем и входите в систему графически, некоторые системы перемещают экземпляр X-сервера с консоли вывода, то есть вы можете переключиться на этот VT и увидеть его. К счастью, обычно это alt-ctrl-f1
выходная консоль для экземпляра alt-ctrl-f7
X и дисплей X, но вы можете проверить столько, сколько сможете найти. Первые 6 обычно порождают логины, но потенциально есть и другие, которые этого не делают и будут отображаться пустыми или с конвейерным выводом. Для некоторых из них может быть вывод из init, не путайте это с выводом из X. По моему опыту, X и дети всегда выдают значительное количество предупреждений и сообщений (о пропущенных шрифтах, обесцененных вызовах и т. Д.).
Если вы не войдете через GUI, это будет тот VT, с которого вы запустили X, что является проблемой, поскольку вы не увидите этого, пока не выйдете. Я полагаю, что при входе в систему через графический интерфейс XDM (графический вход в систему) запускается как привилегированный процесс, что означает, что он может направлять вывод /dev/tty7
. Вы тоже можете ( startx 1>&2> /dev/tty7
), если у вас есть права суперпользователя.
startx
или xinit
непосредственно всегда можно настроить ~/.xinitrc
перенаправление по мере необходимости, прежде чем делать exec
на желаемом оконном менеджере. Сам я никогда не пропускал такой вывод. Если мне интересно, что приложение GUI производит, я запускаю его из терминала. Но на самом деле это может быть полезно, поэтому я перенаправил stdout и stderr of ~/.xinitrc
на ~/.xinitrc.out
.
Если вы берете это, как правило, одна программа запускает другую, выполняя серии, man 2 fork
а man 2 execve
затем в этом процессе по умолчанию файловые дескрипторы остаются открытыми.
Таким образом, ответ заключается в том, что обычно вывод / ошибка происходит там, где вывод / ошибка родительского процесса указывал на время разветвления (если, конечно, родительская программа не выполняет некоторые перенаправления). Я думаю, что вы не можете претендовать на что-то более конкретное, если мы точно не знаем название родительской программы. Процесс оконного менеджера редко участвует в запуске других программ напрямую.
Например в моем случае
xmonad
оконным менеджером) начнетсяdmenu_run
dmenu_run
обработает мой ввод и запустит некоторое приложение (например. xkill
)Выход будет идти, /dev/tty1
потому что
xkill
был начат dmenu_run
dmenu_run
был начат xmonad
xmonad
был начат X
X
был начат startx
startx
был запущен мной вручную с первой виртуальной консоли /dev/tty1
Просто для справки, если вы хотите узнать, куда направляется вывод / ошибка, или лучше сказать, какие файловые дескрипторы открыты для определенного процесса (с известным PID), выполните
$ lsof -p PID
ps faux
чтобы проверить, какой tty / pts связан с процессом. если нет или "?" это вероятно теряется в пустоте. (это просто идея, я могу ошибаться)