Dove va l'output di un'applicazione avviata dal gestore delle finestre?

Se avvii un'applicazione da un terminale puoi vedere l'output su stdout e stderr, ma se un'applicazione viene avviata dal gestore delle finestre, dove va in genere l'output a questi file? A / dev / null?

L'output di un'applicazione avviata dal gestore delle finestre si trova nella stessa posizione dell'output del gestore delle finestre stesso. (A meno che l'applicazione non lo reindirizzi, ma le applicazioni tipiche della GUI no.)

Puoi scoprire dove va l'output di WM guardando cosa ha aperto sul descrittore di file 1 (output standard) e sul descrittore di file 2 (errore standard); in genere entrambi andranno allo stesso file. Scopri l'ID di processo del tuo gestore di finestre (prova ad esempio pgrep metacityo pidof metacityse Metacity è il tuo gestore di finestre - se non conosci il nome del processo per il tuo gestore di finestre, osserva la radice di uno degli alberi di processo riportati da ps fo pstree). Supponendo che l'ID processo del gestore delle finestre sia 1234, eseguire

lsof -p1234

e cercare le righe corrispondenti ai descrittori di file 1 e 2, oppure

o

ls -l /proc/1234/fd

È possibile automatizzare il filtro dei descrittori di file rilevanti:

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

(Nota: tutti i comandi sopra sono per Linux. pgrepÈ comune tra gli altri unices e lsofpuò essere installato praticamente ovunque; le psopzioni e i /proccontenuti sono diversi tra i diversi unices.)

Nella situazione comune in cui si eseguono comandi da una shell in esecuzione in un emulatore di terminale (xterm, konsole, gnome-terminal, ecc., Ma non quando utilizzato su schermo o tmux), è possibile verificare facilmente dove si trova l'output dell'emulatore di terminale sta funzionando, poiché l'emulatore di terminale è il processo principale della shell. Questo non funziona se l'emulatore di terminale è in esecuzione con privilegi aggiuntivi, cosa che accade su alcuni sistemi per consentire all'emulatore di terminale di scrivere nella lista degli utenti registrati (utmp).

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

Molte distribuzioni indirizzano l'output della sessione X a ~/.xsession-errors.

Il gestore delle finestre è figlio del server X, quindi esso e l'output dei relativi figli si trovano nello stesso posto del server X.

Se sei l'unico utente e accedi graficamente, alcuni sistemi spostano l'istanza del server X dalla console di output, il che significa che puoi passare a quel VT e vederlo. Aneddoticamente, la disposizione è di solito quella alt-ctrl-f1della console di output per l'istanza X ed alt-ctrl-f7è il display X, ma puoi verificarne quanti ne puoi trovare. I primi 6 di solito generano accessi, ma ce ne sono potenzialmente altri che non lo fanno e appariranno vuoti o con output in pipe. Potrebbero esserci output su alcuni di essi da init, non confonderlo con l'output di X. Nella mia esperienza X e i bambini abbaiano sempre una quantità significativa di avvisi e messaggi (su font mancanti, chiamate deprezzate, ecc.).

Se non accedi tramite una GUI, sarà qualsiasi VT da cui hai iniziato X, il che è un problema poiché non lo vedrai fino a quando non esci. Credo con un login GUI, XDM (il login grafico) funziona come un processo privilegiato, il che significa che può reindirizzare l'output /dev/tty7. Puoi anche ( startx 1>&2> /dev/tty7) se hai i giusti privilegi di superutente.

Se si considera che in genere un programma ne avvia un altro eseguendo una serie di man 2 forke man 2 execvequindi in quel processo i descrittori di file predefiniti rimangono aperti.

Quindi la risposta è che tipicamente l'output / errore va dove l'output / errore del processo del genitore puntava al momento del fork (a meno che il programma genitore non effettuasse ovviamente alcuni reindirizzamenti). Penso che non si possa pretendere nulla di più specifico se non si conosce esattamente il nome del programma genitore. Il processo di gestione finestre è raramente coinvolto nell'avvio diretto di altri programmi.

Ad esempio nel mio caso

• premendo Ctrl + P (gestito dal xmonadgestore di finestre) verrà avviatodmenu_run
• dmenu_rungestirà il mio input e avvierà alcune applicazioni (ad es. xkill)

L'output andrà a /dev/tty1perché

• xkill è stato avviato da dmenu_run
• dmenu_run è stato avviato da xmonad
• xmonad è stato avviato da X
• X è stato avviato da startx
• startx è stato avviato da me manualmente dalla prima console virtuale /dev/tty1

Solo per riferimento, se vuoi trovare dove va l'output / errore, o meglio dire quali sono i descrittori di file aperti per un particolare processo (con PID noto), fai

$ lsof -p PID