Si inicia una aplicación desde un terminal, puede ver el resultado en stdout y stderr, pero si una aplicación se inicia desde el administrador de ventanas, ¿a dónde suele ir el resultado de estos archivos? Para / dev / null?
~/.xsession-errors
Si inicia una aplicación desde un terminal, puede ver el resultado en stdout y stderr, pero si una aplicación se inicia desde el administrador de ventanas, ¿a dónde suele ir el resultado de estos archivos? Para / dev / null?
~/.xsession-errors
Respuestas:
La salida de una aplicación iniciada desde el administrador de ventanas va al mismo lugar que la salida del administrador de ventanas en sí. (A menos que la aplicación lo redirija, pero las aplicaciones GUI típicas no lo hacen).
Puede averiguar dónde va la salida del WM mirando lo que tiene abierto en el descriptor de archivo 1 (salida estándar) y el descriptor de archivo 2 (error estándar); normalmente ambos irán al mismo archivo. Averigüe la identificación del proceso de su administrador de ventanas (intente, por ejemplo, pgrep metacity
o pidof metacity
si Metacity es su administrador de ventanas; si no conoce el nombre del proceso para su administrador de ventanas, mire la raíz de uno de los árboles de procesos informados por ps f
o pstree
). Supongamos que el ID de proceso de su administrador de ventanas es 1234, ejecute
lsof -p1234
y busque las líneas correspondientes a los descriptores de archivo 1 y 2, o
o
ls -l /proc/1234/fd
Puede automatizar el filtrado de los descriptores de archivo relevantes:
lsof -p1234 | awk '$4 ~ /^[12][^0-9]/'
ls -l /proc/1234/fd/[12]
(Nota: todos los comandos anteriores son para Linux. pgrep
Es común entre otros unices y lsof
puede instalarse prácticamente en cualquier lugar; las ps
opciones y los /proc
contenidos son diferentes en diferentes unices).
En la situación común en la que ejecuta comandos desde un shell que se ejecuta en un emulador de terminal (xterm, konsole, gnome-terminal, etc., pero no cuando se usa en la pantalla o tmux), puede verificar fácilmente dónde está la salida del emulador de terminal va, ya que el emulador de terminal es el proceso principal de su shell. Esto no funciona si el emulador de terminal se ejecuta con privilegios adicionales, lo que sucede en algunos sistemas para permitir que el emulador de terminal escriba en la lista de usuarios registrados (utmp).
lsof -p$PPID
ls -l /proc/$PPID/fd
Muchas distribuciones dirigen la salida de la sesión X a ~/.xsession-errors
.
pidof blackbox
o pgrep blackbox
para obtener el PID del administrador de ventanas, o directamente lsof -p$(pidof blackbox)
. Los ttys no tienen nada que ver con esto.
ls -l /proc/<blackbox-id>/fd
me dice que stdout va a /dev/null
y stderr va a ~/.xsession-errors
.
El gestor de ventanas es el hijo del servidor X, por lo que él y la salida de sus hijos van al mismo lugar que el servidor X.
Si usted es el único usuario e inicia sesión gráficamente, algunos sistemas desplazan la instancia del servidor X de la consola de salida, lo que significa que puede cambiar a ese VT y verlo. Como anécdota, la disposición suele ser alt-ctrl-f1
la consola de salida para la instancia X y alt-ctrl-f7
la pantalla X, pero puede verificar tantas como pueda encontrar. Los primeros 6 generalmente generan inicios de sesión, pero potencialmente hay más que no aparecen y aparecerán en blanco o con salida canalizada. Puede haber salida en algunos de ellos desde init, no confunda eso con la salida de X. En mi experiencia, X y los niños siempre ladran una cantidad significativa de advertencias y mensajes (sobre fuentes faltantes, llamadas depreciadas, etc.).
Si no inicia sesión a través de una GUI, será desde el VT desde el que inició X, lo cual es un problema ya que no lo verá hasta que salga. Creo que con un inicio de sesión GUI, XDM (el inicio de sesión gráfico) se ejecuta como un proceso privilegiado, lo que significa que puede canalizar la salida /dev/tty7
. Usted también puede ( startx 1>&2> /dev/tty7
) si tiene los privilegios de superusuario correctos.
startx
o xinit
directamente, uno siempre puede ajustar ~/.xinitrc
para hacer redirecciones según sea necesario antes de hacerlo exec
en el administrador de ventanas deseado. Yo nunca me he perdido este tipo de salida. Si me interesa saber qué aplicación GUI está produciendo, la ejecuto desde la terminal. Pero en realidad podría ser útil, así que he redirigido stdout y stderr de ~/.xinitrc
a ~/.xinitrc.out
.
Si toma eso, normalmente un programa inicia otro haciendo series de man 2 fork
y man 2 execve
luego, en ese proceso, los descriptores de archivos predeterminados permanecen abiertos.
Entonces, la respuesta es que, por lo general, la salida / error va donde la salida / error del proceso principal apuntaba al tiempo de la bifurcación (a menos que el programa principal realice algunas redirecciones, por supuesto). Creo que no puede reclamar nada más específico a menos que sepamos exactamente el nombre del programa principal. El proceso del administrador de ventanas rara vez participa en el lanzamiento de otros programas directamente.
Por ejemplo en mi caso
xmonad
ventanas) comenzarádmenu_run
dmenu_run
manejará mi entrada e iniciará alguna aplicación (p. ej. xkill
)La salida irá a /dev/tty1
porque
xkill
fue iniciado por dmenu_run
dmenu_run
fue iniciado por xmonad
xmonad
fue iniciado por X
X
fue iniciado por startx
startx
fue iniciado por mí manualmente desde la primera consola virtual /dev/tty1
Solo como referencia, si desea encontrar a dónde va la salida / error, o mejor decir qué son los descriptores de archivo abiertos para un proceso en particular (con PID conocido), haga
$ lsof -p PID
ps faux
para verificar qué tty / pts está asociado con el proceso. si ninguno o "?" probablemente se pierde en el vacío. (esto es solo una idea, puedo estar equivocado)