Trường hợp đầu ra từ một ứng dụng bắt đầu từ trình quản lý cửa sổ đi đâu?


10

Nếu bạn khởi động một ứng dụng từ một thiết bị đầu cuối, bạn có thể thấy đầu ra thành thiết bị xuất chuẩn và thiết bị xuất chuẩn, nhưng nếu một ứng dụng được khởi động từ trình quản lý cửa sổ, thì đầu ra cho các tệp này thường đi đâu? Đến / dev / null?


1
Đề xuất: sử dụng ps fauxđể kiểm tra tty / pts nào được liên kết với quy trình. nếu không có hoặc "?" nó có thể bị lạc trong khoảng trống (đây chỉ là một ý tưởng, tôi có thể sai)
mveroone

@Kwaio: Giá trị là một dấu hỏi (?) Vì vậy, như bạn nói, nó có thể bị mất trong khoảng trống.
Tháng Tám Karlstrom

2
Nếu bạn đã bắt đầu trình bao đồ họa của mình từ gdm hoặc kdm, đầu ra có thể được tìm thấy trong~/.xsession-errors
Shadur

Câu trả lời:


8

Đầu ra của một ứng dụng bắt đầu từ trình quản lý cửa sổ đi đến cùng một nơi với đầu ra từ chính trình quản lý cửa sổ. (Trừ khi ứng dụng chuyển hướng nó, nhưng các ứng dụng GUI thông thường thì không.)

Bạn có thể tìm ra nơi đầu ra của WM đi bằng cách xem những gì nó đã mở trên bộ mô tả tệp 1 (đầu ra tiêu chuẩn) và bộ mô tả tệp 2 (lỗi tiêu chuẩn); thông thường cả hai sẽ đi đến cùng một tập tin. Tìm ra ID tiến trình của trình quản lý cửa sổ của bạn (ví dụ: pgrep metacityhoặc pidof metacityMetacity là trình quản lý cửa sổ của bạn - nếu bạn không biết tên quy trình cho trình quản lý cửa sổ của mình, hãy xem gốc của một trong các cây quy trình được báo cáo bởi ps fhoặc pstree). Giả sử ID tiến trình của trình quản lý cửa sổ của bạn là 1234, hãy chạy

lsof -p1234

và tìm các dòng tương ứng với mô tả tệp 1 và 2, hoặc

hoặc là

ls -l /proc/1234/fd

Bạn có thể tự động lọc các bộ mô tả tệp có liên quan:

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

(Lưu ý: tất cả các lệnh trên là dành cho Linux. pgrepPhổ biến trong số các thông báo khác và lsofcó thể được cài đặt khá nhiều ở mọi nơi; pscác tùy chọn và /procnội dung khác nhau giữa các thông báo khác nhau.)

Trong tình huống phổ biến khi bạn đang chạy các lệnh từ shell chạy trong trình giả lập thiết bị đầu cuối (xterm, konsole, gnome-terminal, v.v., nhưng không phải khi được sử dụng trên màn hình hoặc tmux), thì bạn có thể dễ dàng kiểm tra nơi đầu ra của trình mô phỏng đầu cuối đang diễn ra, vì trình giả lập thiết bị đầu cuối là quá trình cha của shell của bạn. Điều này không hoạt động nếu trình giả lập thiết bị đầu cuối đang chạy với các đặc quyền bổ sung, điều này xảy ra trên một số hệ thống để cho phép trình giả lập thiết bị đầu cuối ghi vào danh sách người dùng đã đăng nhập (utmp).

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

Nhiều bản phân phối chỉ đạo đầu ra của phiên X tới ~/.xsession-errors.


Trong trường hợp của tôi, hệ thống phân cấp cha-con bắt đầu từ WM là hộp đen <- lightdm <- lightdm <- init và tất cả các ttys đều có giá trị "?". Tôi đoán sau đó đầu ra không đi đến đâu.
Tháng Tám Karlstrom

@AugustKarlstrom Sau đó pidof blackboxhoặc pgrep blackboxđể lấy PID của trình quản lý cửa sổ, hoặc trực tiếp lsof -p$(pidof blackbox). Ttys không có gì để làm với điều này.
Gilles 'SO- ngừng trở nên xấu xa'

1
À, tất nhiên rồi. Lệnh ls -l /proc/<blackbox-id>/fdcho tôi biết rằng stdout đi đến /dev/nullvà stderr đi đến ~/.xsession-errors.
Tháng Tám Karlstrom

1

Trình quản lý cửa sổ là con của máy chủ X, vì vậy nó và đầu ra con của nó đi đến cùng một nơi với máy chủ X.

Nếu bạn là người dùng duy nhất và bạn đăng nhập bằng đồ họa, một số hệ thống thay thế phiên bản máy chủ X từ bảng điều khiển đầu ra, nghĩa là bạn có thể chuyển sang VT đó và xem nó. Thông thường, sự sắp xếp thường alt-ctrl-f1là bàn điều khiển đầu ra cho thể hiện X và alt-ctrl-f7là màn hình X, nhưng bạn có thể kiểm tra bao nhiêu tùy ý. 6 đăng nhập đầu tiên thường sinh ra, nhưng có nhiều khả năng không và sẽ xuất hiện trống hoặc với đầu ra đường ống. Có thể có đầu ra trên một số trong số chúng từ init, đừng nhầm lẫn rằng với đầu ra từ X. Theo kinh nghiệm của tôi, X và trẻ em luôn đưa ra một số lượng đáng kể các cảnh báo và tin nhắn (về phông chữ bị thiếu, các cuộc gọi bị mất giá, v.v.).

Nếu bạn không đăng nhập qua GUI, đó sẽ là bất cứ điều gì VT bạn bắt đầu X từ đó, đây là một vấn đề vì bạn sẽ không thấy điều đó cho đến khi bạn thoát. Tôi tin rằng với thông tin đăng nhập GUI, XDM (đăng nhập đồ họa) chạy như một quy trình đặc quyền, có nghĩa là nó có thể dẫn đầu ra /dev/tty7. Bạn cũng có thể ( startx 1>&2> /dev/tty7) nếu bạn có các đặc quyền siêu người dùng phù hợp.


1
Trong trường hợp startxhoặc xinittrực tiếp, người ta luôn có thể điều chỉnh ~/.xinitrcđể thực hiện chuyển hướng khi cần thiết trước khi thực hiện exectrên trình quản lý cửa sổ mong muốn. Bản thân tôi chưa bao giờ bỏ lỡ loại đầu ra này. Nếu tôi quan tâm ứng dụng GUI nào đang sản xuất, tôi sẽ chạy nó từ thiết bị đầu cuối. Nhưng trên thực tế nó có thể hữu ích vì vậy tôi đã chuyển hướng stdout và stderr của ~/.xinitrcđể ~/.xinitrc.out.
Miroslav Koškár

0

Nếu bạn lấy đó thường thì một chương trình sẽ bắt đầu một chương trình khác bằng cách thực hiện một loạt man 2 forkman 2 execvesau đó trong quy trình đó theo mô tả tệp mặc định vẫn mở.

Vì vậy, câu trả lời là thông thường đầu ra / lỗi xuất hiện ở nơi đầu ra / lỗi quá trình của cha mẹ chỉ vào thời gian rẽ nhánh (trừ khi chương trình cha mẹ thực hiện một số chuyển hướng tất nhiên). Tôi nghĩ bạn không thể yêu cầu bất cứ điều gì cụ thể hơn trừ khi chúng tôi biết chính xác tên của chương trình phụ huynh. Quá trình quản lý cửa sổ hiếm khi liên quan đến việc khởi chạy các chương trình khác trực tiếp.

Ví dụ trong trường hợp của tôi

  • nhấn Ctrl + P (được xử lý bởi xmonadtrình quản lý cửa sổ) sẽ bắt đầudmenu_run
  • dmenu_runsẽ xử lý đầu vào của tôi và bắt đầu một số ứng dụng (ví dụ. xkill)

Đầu ra sẽ đi đến /dev/tty1bởi vì

  • xkill được bắt đầu bởi dmenu_run
  • dmenu_run được bắt đầu bởi xmonad
  • xmonad được bắt đầu bởi X
  • X được bắt đầu bởi startx
  • startx được tôi bắt đầu bằng tay từ bàn điều khiển ảo đầu tiên /dev/tty1

Chỉ để tham khảo, nếu bạn muốn tìm nơi xuất / lỗi, hoặc nói rõ hơn là các mô tả tệp được mở cho một quy trình cụ thể (với PID đã biết), hãy làm

$ lsof -p PID
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.