Where does the output from an application started from the window manager go?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 xmonad window manager) will start dmenu_run
• dmenu_run will handle my input and start some application (eg. xkill)

The output will go to /dev/tty1 because

• xkill was started by dmenu_run
• dmenu_run was started by xmonad
• xmonad was started by X
• X was started by startx
• startx was 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