Gdzie idzie wyjście z aplikacji uruchomionej z menedżera okien?

10

Jeśli uruchamiasz aplikację z terminala, możesz wyświetlić dane wyjściowe na stdout i stderr, ale jeśli aplikacja jest uruchamiana z menedżera okien, gdzie zwykle trafia dane wyjściowe do tych plików? Do / dev / null?

xorg logs stdout

— August Karlstrom
źródło

1

Sugestia: użyj, ps fauxaby sprawdzić, który tty / pts jest powiązany z procesem. jeśli brak lub „?” prawdopodobnie gubi się w pustce. (to tylko pomysł, mogę się mylić)

— mveroone

@Kwaio: Wartość jest znakiem zapytania (?), Więc, jak mówisz, prawdopodobnie gubi się w pustce.

— Sierpień Karlstrom,

2

Jeśli uruchomiłeś graficzną powłokę z gdm lub kdm, dane wyjściowe można znaleźć w~/.xsession-errors

— Shadur,

8

Dane wyjściowe aplikacji uruchomionej z menedżera okien trafiają w to samo miejsce, co dane wyjściowe z samego menedżera okien. (O ile aplikacja go nie przekieruje, ale typowe aplikacje GUI tego nie robią).

Możesz dowiedzieć się, dokąd idzie wyjście WM, patrząc na to, co jest otwarte w deskryptorze pliku 1 (standardowe wyjście) i deskryptorze pliku 2 (błąd standardowy); zazwyczaj oba przejdą do tego samego pliku. Znajdź identyfikator procesu menedżera okien (spróbuj np. pgrep metacityLub pidof metacityjeśli Metacity jest menedżerem okien - jeśli nie znasz nazwy procesu menedżera okien, spójrz na katalog główny jednego z drzew procesów zgłoszonych przez ps flub pstree). Załóżmy, że identyfikator procesu menedżera okien to 1234, uruchom

lsof -p1234

i poszukaj wierszy odpowiadających deskryptorom plików 1 i 2 lub

lub

ls -l /proc/1234/fd

Możesz zautomatyzować filtrowanie odpowiednich deskryptorów plików:

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

(Uwaga: wszystkie powyższe polecenia dotyczą Linuksa. pgrepJest wspólne dla innych jednorożców i lsofmożna je zainstalować praktycznie wszędzie; psopcje i /proczawartość są różne dla różnych jednorożców).

W typowej sytuacji, w której uruchamiasz polecenia z powłoki uruchomionej w emulatorze terminali (xterm, konsola, terminal gnome itp., Ale nie używasz ich przez ekran lub tmux), możesz łatwo sprawdzić, gdzie jest wyjście emulatora terminala idzie, ponieważ emulator terminala jest procesem nadrzędnym powłoki. Nie działa to, jeśli emulator terminala działa z dodatkowymi uprawnieniami, co ma miejsce w niektórych systemach, aby umożliwić emulatorowi terminala zapisywanie na liście zalogowanych użytkowników (utmp).

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

Wiele dystrybucji kieruje dane wyjściowe sesji X do ~/.xsession-errors.

— Gilles „SO- przestań być zły”
źródło

W moim przypadku hierarchią potomek-rodzic zaczynającą się od WM jest blackbox <- lightdm <- lightdm <- init, a wszystkie tty mają wartość „?”. Sądzę więc, że wyjście nie prowadzi do nikąd.

— August Karlstrom,

@ AugustKarlstrom Następnie pidof blackboxlub, pgrep blackboxaby uzyskać PID menedżera okien lub bezpośrednio lsof -p$(pidof blackbox). Ttys nie mają z tym nic wspólnego.

— Gilles „SO- przestań być zły”

1

Ach, oczywiście. Polecenie ls -l /proc/<blackbox-id>/fdmówi mi, że stdout idzie do, /dev/nulla stderr idzie do ~/.xsession-errors.

— August Karlstrom,

1

Menedżer okien jest potomkiem serwera X, więc dane wyjściowe i jego dzieci idą w to samo miejsce co serwer X.

Jeśli jesteś jedynym użytkownikiem i logujesz się graficznie, niektóre systemy usuwają instancję serwera X z konsoli wyjściowej, co oznacza, że możesz przełączyć się do tego VT i go zobaczyć. Anegdotycznie, układ jest zwykle taki, który alt-ctrl-f1jest konsolą wyjściową dla instancji X i alt-ctrl-f7jest wyświetlaczem X, ale można sprawdzić tyle, ile można znaleźć. Pierwsze 6 zwykle odradza logowanie, ale potencjalnie jest więcej takich, które się nie pojawią i będą puste lub z wyjściem potokowym. Niektóre z nich mogą mieć wyjście z init, nie myl tego z wyjściem z X. Z mojego doświadczenia wynika, że X i dzieci zawsze szczekają znaczną liczbę ostrzeżeń i wiadomości (o brakujących czcionkach, nieaktualnych wywołaniach itp.).

Jeśli nie zalogujesz się za pomocą GUI, będzie to każdy VT, z którego uruchomiłeś X, co stanowi problem, ponieważ nie zobaczysz tego, dopóki nie wyjdziesz. Uważam, że przy logowaniu GUI XDM (logowanie graficzne) działa jako proces uprzywilejowany, co oznacza, że może przesyłać dane wyjściowe /dev/tty7. Możesz także ( startx 1>&2> /dev/tty7), jeśli masz odpowiednie uprawnienia administratora.

— Złotowłosa
źródło

1

W przypadku startxlub xinitbezpośrednio można zawsze dostosować, ~/.xinitrcaby wykonać przekierowania w razie potrzeby przed wykonaniem execżądanego menedżera okien. Sam nigdy nie przegapiłem tego rodzaju wyników. Jeśli jestem zainteresowany tym, co tworzy aplikacja GUI, uruchamiam ją z terminala. Ale tak naprawdę może to być pomocne, więc przekierowałem stdout i stderr ~/.xinitrcna ~/.xinitrc.out.

— Miroslav Koškár

0

Jeśli przyjmujesz, że zwykle jeden program uruchamia inny, wykonując serię, man 2 forka man 2 execvenastępnie domyślnie deskryptory plików pozostają otwarte.

Tak więc odpowiedź jest taka, że zazwyczaj wyjście / błąd idzie tam, gdzie dane wyjściowe / błąd procesu nadrzędnego wskazywały na czas rozwidlenia (chyba że program nadrzędny dokonuje pewnych przekierowań). Myślę, że nie można domagać się niczego bardziej szczegółowego, jeśli nie znamy dokładnie nazwy programu nadrzędnego. Proces menedżera okien rzadko bierze udział w bezpośrednim uruchamianiu innych programów.

Na przykład w moim przypadku

naciśnięcie Ctrl + P (obsługiwane przez xmonadmenedżera okien) rozpocznie siędmenu_run
dmenu_runobsłuży moje dane wejściowe i uruchomi niektóre aplikacje (np. xkill)

Wyjście przejdzie do, /dev/tty1ponieważ

xkill został założony przez dmenu_run
dmenu_run został założony przez xmonad
xmonad został założony przez X
X został założony przez startx
startx został uruchomiony przeze mnie ręcznie z pierwszej wirtualnej konsoli /dev/tty1

Dla odniesienia, jeśli chcesz dowiedzieć się, gdzie idzie wyjście / błąd, lub lepiej powiedzieć, jakie deskryptory plików są otwarte dla określonego procesu (ze znanym PID), wykonaj

$ lsof -p PID

— Miroslav Koškár
źródło