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?
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 blackbox
orpgrep blackbox
to get the PID of the window manager, or directlylsof -p$(pidof blackbox)
. Ttys have nothing to do with this. – Gilles 'SO- stop being evil' Aug 15 '13 at 15:00 -
1Ah, of course. The command
ls -l /proc/<blackbox-id>/fd
tells me that stdout goes to/dev/null
and stderr goes to~/.xsession-errors
. – August Karlstrom Aug 15 '13 at 15:07
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.
-
1In case of
startx
orxinit
directly one can always tweak~/.xinitrc
to do redirections as needed before doingexec
on 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~/.xinitrc
to~/.xinitrc.out
. – Miroslav Koškár Aug 14 '13 at 15:35
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 startdmenu_run
dmenu_run
will handle my input and start some application (eg.xkill
)
The output will go to /dev/tty1
because
xkill
was started bydmenu_run
dmenu_run
was started byxmonad
xmonad
was started byX
X
was started bystartx
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
ps faux
to 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