spaf@cs.purdue.EDU (Gene Spafford) (03/04/88)
I'm running SunOS 3.4 on a Sun 3/50. I just built and installed
X.V11R2 and have discovered the same problem that I had with version 1
-- I can't start up X when my login shell is ksh.
When I run xinit, I get the message about waiting for the server to
start, followed by an continuing line of dots. A ps shows the X server
running, but the characteristic root window never shows up. If I
switch to the csh or Bourne shell and log in again, everything behaves
just fine and starts up properly.
I don't have the time, energy, or patience to try to track this down
right now. Has anyone out there seen the same problem? Got any fixes
or suggestions to pass along? I'd love to switch to X from Sunwindows,
but I refuse to switch from ksh at this point!
Thanks in advance!
--
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spafconway@hplb29a.HPL.HP.COM (Daniel F. Conway) (03/05/88)
/ hplb29a:comp.windows.x / spaf@cs.purdue.EDU (Gene Spafford) / 5:52 pm Mar 3, 1988 / > > > When I run xinit, I get the message about waiting for the server to > start, followed by an continuing line of dots. A ps shows the X server > running, but the characteristic root window never shows up. If I > switch to the csh or Bourne shell and log in again, everything behaves > just fine and starts up properly. > > Gene Spafford I had a similar problem when I first tried to run X windows - it would not run with csh, displaying similar problems to what you describe. It would run with sh or ksh, though. After considerable head-scratching, I finally tracked to problem down to two environment variables that were being set in .cshrc: XFONTPATH and DISPLAY. It turned out that these were bogus, and were left over from some incorrect X installation documentation that I had gotten. Try looking at your environments with the different shells; I'll bet that you have some bad environment variable set with ksh. Dan Conway Hewlett-Packard Palo Alto, CA dan_conway@hplabs.hp.com . . . hplabs!dan_conway
spaf@cs.purdue.EDU (Gene Spafford) (03/09/88)
A few days ago, I posted a request for help. The problem I had was
that if I ran "xinit" under the ksh, the server just hung and never
finished starting up. I narrowed the problem down further to find that
only if I had the monitor (jobs facility) option set did the problem
occur.
Well, after an afternoon and evening of intense frustration debugging,
I found the problem. The following is a description of the problem and
a workaround; the bug and some approaches to fixes have been submitted
to the official buglist, but this may help others soon to encounter
similar problems.
When "xinit" starts the server, it resets the process group of the
process running the X server (Xsun in my case) to 0 so it is in a
different process group than the xinit process. This is to prevent a
problem that will not occur on a Sun -- that of the companion client
process being spawned with the -L flag, and having a subsequent
vhangup() call blow the parent processes away. Unfortunately, one of
the first things done by the new X server process is a
"write(2, buffer, 0)" to see if the fd is open for error messages.
Since the process no longer belongs to the distinguished process group
of the terminal where unit 2 is open, it gets a SIGTTOU and blocks.
Workaround is simple: run xinit with stderr redirected to a file or
pipe. I now run ksh out of my .profile with:
(xinit $HOME/bin/xstart; kbd_mode -a; clear) 2>&1 | cat -u
Ugly maybe, but it works just fine.
Mark Moraes @ University of Toronto sent me a patch he developed to get
newcsh and tcsh running under X11.1. He suggests I "#ifndef sun" the
setpgrp causing the problem. Unfortunately, the killpg mechanism in
use causes the parent ksh to die when xinit terminates if this change
is applied. Hopefully the people supporting X11 will come up with a
better, "official" fix.
--
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf