¿A dónde va la salida de una aplicación iniciada desde el administrador de ventanas?
10
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?
Sugerencia: use ps fauxpara 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)
mveroone
@Kwaio: El valor es un signo de interrogación (?) Así que, como usted dice, probablemente se pierda en el vacío.
August Karlstrom
2
Si usted comenzó su consola gráfica de GDM o KDM la salida se puede encontrar en~/.xsession-errors
Shadur
Respuestas:
8
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 metacityo pidof metacitysi 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 fo 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. pgrepEs común entre otros unices y lsofpuede instalarse prácticamente en cualquier lugar; las psopciones y los /proccontenidos 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.
En mi caso, la jerarquía padre-hijo que comienza desde el WM es blackbox <- lightdm <- lightdm <- init y todos los ttys tienen el valor "?". Supongo que la salida no va a ninguna parte.
August Karlstrom
@AugustKarlstrom Entonces pidof blackboxo pgrep blackboxpara obtener el PID del administrador de ventanas, o directamente lsof -p$(pidof blackbox). Los ttys no tienen nada que ver con esto.
Gilles 'SO- deja de ser malvado'
1
Ah, por supuesto. El comando ls -l /proc/<blackbox-id>/fdme dice que stdout va a /dev/nully stderr va a ~/.xsession-errors.
August Karlstrom
1
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-f1la consola de salida para la instancia X y alt-ctrl-f7la 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.
En caso de startxo xinitdirectamente, uno siempre puede ajustar ~/.xinitrcpara hacer redirecciones según sea necesario antes de hacerlo execen 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 ~/.xinitrca ~/.xinitrc.out.
Miroslav Koškár
0
Si toma eso, normalmente un programa inicia otro haciendo series de man 2 forky man 2 execveluego, 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
presionando Ctrl + P (manejado por el administrador de xmonadventanas) comenzarádmenu_run
dmenu_runmanejará mi entrada e iniciará alguna aplicación (p. ej. xkill)
La salida irá a /dev/tty1porque
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
ps fauxpara 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)~/.xsession-errorsRespuestas:
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 metacityopidof metacitysi 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 porps fopstree). Supongamos que el ID de proceso de su administrador de ventanas es 1234, ejecutey busque las líneas correspondientes a los descriptores de archivo 1 y 2, o
o
Puede automatizar el filtrado de los descriptores de archivo relevantes:
(Nota: todos los comandos anteriores son para Linux.
pgrepEs común entre otros unices ylsofpuede instalarse prácticamente en cualquier lugar; laspsopciones y los/proccontenidos 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).
Muchas distribuciones dirigen la salida de la sesión X a
~/.xsession-errors.fuente
pidof blackboxopgrep blackboxpara obtener el PID del administrador de ventanas, o directamentelsof -p$(pidof blackbox). Los ttys no tienen nada que ver con esto.ls -l /proc/<blackbox-id>/fdme dice que stdout va a/dev/nully 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-f1la consola de salida para la instancia X yalt-ctrl-f7la 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.fuente
startxoxinitdirectamente, uno siempre puede ajustar~/.xinitrcpara hacer redirecciones según sea necesario antes de hacerloexecen 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~/.xinitrca~/.xinitrc.out.Si toma eso, normalmente un programa inicia otro haciendo series de
man 2 forkyman 2 execveluego, 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
xmonadventanas) comenzarádmenu_rundmenu_runmanejará mi entrada e iniciará alguna aplicación (p. ej.xkill)La salida irá a
/dev/tty1porquexkillfue iniciado pordmenu_rundmenu_runfue iniciado porxmonadxmonadfue iniciado porXXfue iniciado porstartxstartxfue iniciado por mí manualmente desde la primera consola virtual/dev/tty1Solo 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
fuente