If you start an application from a terminal you can see the output to stdout and stderr, but if an application is started from the window manager, where does the output to these files typically go? To /dev/null?
10
asked Aug 14 '13 at 9:02
migrated from serverfault.com Aug 14 '13 at 13:06
This question came from our site for system and network administrators.
8
The output of an application started from the window manager goes to the same place as the output from the window manager itself. (Unless the application redirects it, but typical GUI applications don't.)
You can find out where the WM's output goes by looking at what it has open on file descriptor 1 (standard output) and file descriptor 2 (standard error); typically both will go to the same file. Find out the process ID of your window manager (try e.g. pgrep metacity or pidof metacity if Metacity is your window manager — if you don't know the process name for your window manager, look at the root of one of the process trees reported by ps f or pstree). Supposing the process ID of your window manager is 1234, run
lsof -p1234
and look for the lines corresponding to file descriptors 1 and 2, or
or
ls -l /proc/1234/fd
You can automate the filtering of the relevant file descriptors:
lsof -p1234 | awk '$4 ~ /^[12][^0-9]/'
ls -l /proc/1234/fd/[12]
(Note: all the commands above are for Linux. pgrep is common among other unices, and lsof can be installed pretty much anywhere; ps options and /proc contents are different across different unices.)
In the common situation where you're running commands from a shell running in a terminal emulator (xterm, konsole, gnome-terminal, etc., but not when used across screen or tmux), then you can easily check where the terminal emulator's output is going, as the terminal emulator is the parent process of your shell. This doesn't work if the terminal emulator is running with additional privileges, which happens on some systems to allow the terminal emulator to write to the logged-in user list (utmp).
lsof -p$PPID
ls -l /proc/$PPID/fd
Many distributions direct the output of the X session to ~/.xsession-errors.
-
In my case the child-parent hierarchy starting from the WM is blackbox <- lightdm <- lightdm <- init and all the ttys have the value "?". I guess then that the output goes nowhere. – August Karlstrom Aug 15 '13 at 14:59
-
@AugustKarlstrom Then
pidof blackboxorpgrep blackboxto get the PID of the window manager, or directlylsof -p$(pidof blackbox). Ttys have nothing to do with this. – Gilles Aug 15 '13 at 15:00 -
1Ah, of course. The command
ls -l /proc/<blackbox-id>/fdtells me that stdout goes to/dev/nulland stderr goes to~/.xsession-errors. – August Karlstrom Aug 15 '13 at 15:07
1
The window manager is the child of the X server, so it and its children's output go to the same place as the X server.
If you are the only user and you login graphically, some systems displace the X server instance from the output console, meaning you can switch to that VT and see it. Anecdotally, the arrangement is usually that alt-ctrl-f1 is the output console for the X instance and alt-ctrl-f7 is the X display, but you can check as many as you can find. The first 6 usually spawn logins, but there are potentially more that do not and will appear blank or with piped output. There might be output on some of them from init, don't confuse that with output from X. In my experience X and children always bark up a significant amount of warnings and messages (about missing fonts, depreciated calls, etc).
If you don't log in via a GUI, it will be whatever VT you started X from, which is a problem since you won't see that until you quit. I believe with a GUI login, XDM (the graphical login) runs as a privileged process, meaning it can pipe output to /dev/tty7. You can too (startx 1>&2> /dev/tty7) if you have the right superuser privileges.
answered Aug 14 '13 at 14:07
-
1In case of
startxorxinitdirectly one can always tweak~/.xinitrcto do redirections as needed before doingexecon desired window manager. Myself I've never missed this kind of output. If I'm interested what GUI application is producing I run it from terminal. But actually it might be helpful so I've redirected stdout and stderr of~/.xinitrcto~/.xinitrc.out. – Miroslav Koškár Aug 14 '13 at 15:35
0
If you take that typically one program starts another by doing series of man 2 fork and man 2 execve then in that process by default file descriptors remain open.
So the answer is that typically the output / error goes where parent's process output / error was pointing at fork time (unless the parent program does some redirections of course). I think you can't claim anything more specific unless we know the name of the parent program exactly. Window manager process is rarely involved in launching other programs directly.
For example in my case
- pressing Ctrl+P (handled by
xmonadwindow manager) will startdmenu_run dmenu_runwill handle my input and start some application (eg.xkill)
The output will go to /dev/tty1 because
xkillwas started bydmenu_rundmenu_runwas started byxmonadxmonadwas started byXXwas started bystartxstartxwas started by me manually from first virtual console/dev/tty1
Just for a reference, if you want to find where output / error goes, or better say what are file descriptors opened for a particular process (with known PID), do
$ lsof -p PID
ps fauxto check which tty/pts is associated with the process. if none or "?" it probably gets lost in the void. (this is just an idea, i can be wrong) – mveroone Aug 14 '13 at 9:39~/.xsession-errors– Shadur Aug 14 '13 at 13:50