How to get X output redirection back
X stopped working after my last Debian update.
Rather than run a login manager, I typically log in on the console. Then in my .zlogin file, I have:
if [[ $(tty) == /dev/tty1 ]]; then # do various things first, then: startx -- -dumbSched >& $HOME/.xsession-errors fiIgnore
-dumbSched
for now; it's a fix for a timing problem
openbox has when bringing up initial windows. The relevant part here
is that I redirect both standard output and standard error to a
file named .xsession-errors. That means that if I run GIMP or firefox
or any other program from a menu, and later decide I need to see
their output to look for error messages, all I have to do is check
that file.
But as of my last update, that no longer works.
Plain startx
, without the output redirection, works fine.
But with the redirect, X pauses for five or ten seconds, then exits,
giving me my prompt back but with messed-up terminal settings, so I
have to type reset
before I do anything else.
Of course, I checked that .xsession file for errors, and also the ~/.local/share/xorg/Xorg.0.log file it referred me to (which is where X stores its log now that it's no longer running as root). It seems the problem is this:
Fatal server error: (EE) xf86OpenConsole: VT_ACTIVATE failed: Operation not permittedWhich wasn't illuminating but at least gave me a useful search keyword.
I found a fair number of people on the web having the same problem. It's related to the recent Xorg change that makes it possible to run Xorg as a regular user, not root. Not that running as a user should have anything to do with capturing standard output and error. But apparently Xorg running as a user is dependent on what sort of virtual terminal it was run from; and the way it determines the controlling terminal, apparently, is by checking stderr (and maybe also stdout).
Here's a slightly longer description of what it's doing, from the ever useful Arch Linux forums.
I'm fairly sure there are better ways of determining a process's
controlling terminal than using stderr. For instance, a casual web
search turned up ctermid;
or you could do checks on /dev/tty
. There are probably
other ways.
The Arch Linux thread linked above, and quite a few others, suggest
adding the server option -keeptty
when starting X. The
Xorg manual isn't encouraging about this as a solution:
But it does work.
- -keeptty
- Prevent the server from detaching its initial controlling terminal. This option is only useful when debugging the server. Not all platforms support (or can use) this option.
I found several bugs filed already on the redirection problem. Freedesktop has a bug report on it, but it's more than a year old and has no comments or activity: Freedesktop bug 82732: rootless X doesn't start if stderr redirected.
Redhat has a bug report:
Xorg
without root rights breaks by streams redirection,
and supposedly added a fix way back in January
in their package version xorg-x11-xinit-1.3.4-3.fc21 ...
though it looks like
their
fix is simply to enable -keeptty
automatically,
which is better than nothing but doesn't seem ideal.
Still, it does suggest that it's probably not harmful to use that
workaround and ignore what the Xorg man page says.
Debian didn't seem to have a bug filed on the problem yet (not
terribly surprising, since they only enabled it in unstable a
few days ago), so I used reportbug
to attempt to file one.
I would link to it here if Debian had an actual bug system that
allowed searching for bugs (they do have a page entitled "BTS Search"
but it gives "Internal Server Error", and the alternate google groups
bug search doesn't find my bug), or if their bug reporting system
acknowledged new bugs by emailing the submitter the bug number.
In truth I strongly suspect that reportbug
is actually a
no-op and doesn't actually do anything with the emailed report.
But I'm not sure the Debian bug matters since the real bug is Xorg's,
and it doesn't look like they're very interested in the problem.
So anyone who wants to be able to access output of programs running
under X probably needs to use -keeptty
for the forseeable
future.
Update: the bug acknowledgement came in six hours later. It's bug 801529.
[ 12:31 Oct 11, 2015 More linux | permalink to this entry | ]