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?
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,
Odpowiedzi:
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
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.
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.
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
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ć)~/.xsession-errorsOdpowiedzi:
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 metacityLubpidof 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 przezps flubpstree). Załóżmy, że identyfikator procesu menedżera okien to 1234, uruchomi poszukaj wierszy odpowiadających deskryptorom plików 1 i 2 lub
lub
Możesz zautomatyzować filtrowanie odpowiednich deskryptorów plików:
(Uwaga: wszystkie powyższe polecenia dotyczą Linuksa.
pgrepJest wspólne dla innych jednorożców ilsofmoż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).
Wiele dystrybucji kieruje dane wyjściowe sesji X do
~/.xsession-errors.źródło
pidof blackboxlub,pgrep blackboxaby uzyskać PID menedżera okien lub bezpośredniolsof -p$(pidof blackbox). Ttys nie mają z tym nic wspólnego.ls -l /proc/<blackbox-id>/fdmówi mi, że stdout idzie do,/dev/nulla stderr idzie do~/.xsession-errors.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 ialt-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.źródło
startxlubxinitbezpośrednio można zawsze dostosować,~/.xinitrcaby wykonać przekierowania w razie potrzeby przed wykonaniemexecżą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.Jeśli przyjmujesz, że zwykle jeden program uruchamia inny, wykonując serię,
man 2 forkaman 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
xmonadmenedżera okien) rozpocznie siędmenu_rundmenu_runobsłuży moje dane wejściowe i uruchomi niektóre aplikacje (np.xkill)Wyjście przejdzie do,
/dev/tty1ponieważxkillzostał założony przezdmenu_rundmenu_runzostał założony przezxmonadxmonadzostał założony przezXXzostał założony przezstartxstartxzostał uruchomiony przeze mnie ręcznie z pierwszej wirtualnej konsoli/dev/tty1Dla 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
źródło