10

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?

|improve this question
  • 1
    Suggestion : use 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
  • @Kwaio: The value is a question mark (?) so, as you say, it probably gets lost in the void. – August Karlstrom Aug 14 '13 at 10:10
  • 2
    If you started your graphical shell from gdm or kdm the output can be found in ~/.xsession-errors – Shadur Aug 14 '13 at 13:50
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.

|improve this answer
  • 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 or pgrep blackbox to get the PID of the window manager, or directly lsof -p$(pidof blackbox). Ttys have nothing to do with this. – Gilles 'SO- stop being evil' Aug 15 '13 at 15:00
  • 1
    Ah, 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
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.

|improve this answer
  • 1
    In case of startx or xinit directly one can always tweak ~/.xinitrc to do redirections as needed before doing exec 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
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 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
|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.