Re: problem regarding setting DISPLAY env variable and hostname
- From: Rob <rob@xxxxxxxxxxxx>
- Date: Thu, 23 Feb 2006 14:13:15 -0800
On Thu, 23 Feb 2006 23:29:47 +0200
Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
Please try to interleave the replies with quoted material. It's
much easier to read related stuff if it close together, instead
of having to page up and down my entire original reply :(
I am sorry. I sometimes don't know when I should do this as I have
seen the debates on -questions about top posting, bottom posting, etc.
I've reorganized this post and moved things around, so you may
find that the numbering of your text is not exactly consecutive.
Sorry about this, but I can't reply to a long multi-page message
by constantly moving up and down.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
On Thu, 23 Feb 2006 19:26:28 +0200
Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
1. 127.0.0.1 localhost xenon
2 127.0.0.1 localhost
What are the "1." and "2" at the beginning of the lines above?
I hope they are not part of your /etc/hosts file.
You have obviously messed up your /etc/hosts file too much.
Before you do anything else, please restore it from the sources,
by copying `/usr/src/etc/hosts' over it. Then re-add "xenon" at
the localhost line.
Here are all of the steps which I have just done:
I. I copied /usr/src/etc/hosts to /etc/hosts. Now it looks like:
::1 localhost localhost.my.domain
127.0.0.1 localhost localhost.my.domain
everything else is commented out
That's not exactly what I said though. You missed re-adding the
"xenon" entry, so you are back to square one, with "xenon" being
unresolvable.
After I tried the above /etc/hosts file, I did change it to:
::1 localhost xenon
127.0.0.1 localhost xenon
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
On Thu, 23 Feb 2006 19:26:28 +0200
Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
The only thing that I have done which changes the error message is to
set /etc/rc.conf hostname="xenon" Then in .bash_profile put
"DISPLAY=xenon:0.0 export DISPLAY"
No. That's a *horrible* idea. The `startx' utility can start an X11
server with a slightly different display, i.e. with:
$ startx -- :1
Then your .bash_profile will override the default DISPLAY of the X11
session, messing up everything. If you happen to run two X11 sessions
at the same time, you will be opening windows in the first session no
matter where you run the commands that you will use.
4. The user .bash_profile no longer has the "DISPLAY=xenon:0.0
export DISPLAY" in it. The .xinitrc no longer has the xdpyinfo
-display :0.0 line in it.
You don't need to include DISPLAY in your .bash_profile. As I
have tried to emphasize, this is wrong and can even prove harmful
if you ever find yourself in the need for multiple X11 sessions.
You have done a good thing when you removed the xdpyinfo command too.
Yes, both the DISPLAY variable and xdpyinfo are gone for good.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
On Thu, 23 Feb 2006 19:26:28 +0200
Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
Then I get the different error message:
"_X11TransSocketINETConnect() can't get address for xenon:6000: hostname nor servname provided, or not known
Error: Can't open display: xenon:0.0"
The error message means you still have name resolution problems. Your
system doesn't know that "xenon", "localhost", "127.0.0.1" are all
equivalents ways of referring to itself.
So I guess now I have tried every combination of the following:
setting hostname in rc.conf to either "" or "xenon"
setting "DISPLAY=xenon:0.0" or leaving that line out in .bash_profile
A hostname of "" is wrong.
A hostname of "xenon" is almost right.
2. I confirmed that hostname="xenon" is still in rc.conf
Very nice. That's the spirit :)
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
On Thu, 23 Feb 2006 19:26:28 +0200
Giorgos Keramidas <keramida@xxxxxxxxxxxxxxx> wrote:
And finally, putting in xinitrc "xdpyinfo -display :0.0 or just
leaving that line out.
This should be without any real side-effects regarding the way your X11
session works.
Please, restore your /etc/hosts file from /usr/src/etc/hosts and then
we'll see what other may be wrong with your current setup.
3. I checked /root/.cshrc has no Xorg related commands in it,
just a couple of aliases that I added to the original file.
Nice thing too.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
5. I rebooted. Sendmail starts up fine now.
6. So I started up Xorg and I get the errors on startup:
bad display name "xenon:0 in "list" command
and then upon Xorg shutdown:
bad display name "xenon:0" in "remove" command
Now that you have removed "xenon" from /etc/hosts, there's no way
to resolve this name. This is an expected error, I guess.
After I added "xenon" to /etc/hosts, the error messages went away again.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
7. I gave the command "xhost +localhost" at the xterm prompt
I get: localhost being added to access control list
8. I su at the xterm prompt and then give the command
setenv DISPLAY localhost:0.0 all ok
9. then I try to run an X related program from the xterm command prompt
and get the error:
Error: Can't open display localhost:0.0
Now we're getting close.
What is probably happening now is that your X11 server has
started fine, but is not listening for network connections.
Can you check with sockstat(1) to see if the X server is
listening to port 6000 (this is what DISPLAY=:0 actually means)?
An example of running sockstat to do this would be:
keramida@flame:/home/keramida$ sockstat -l4 -p 6000
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root Xorg 876 3 tcp4 *:6000 *:*
keramida@flame:/home/keramida$
If you don't see something like this, but you get an empty port list
instead, like this one:
keramida@flame:/home/keramida$ sockstat -l4 -p 6000
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
keramida@flame:/home/keramida$
Aha! Yes, I got the empty sockstat list.
Then you have two options:
1. Start the X11 server in ``listen mode'', which will enable
connections to port 6000:
$ startx -listen_tcp
I tried that and then at the xterm I again gave the commands
xhost +localhost
su'd
setenv DISPLAY localhost:0.0
And I was able to run X programs as root, so that worked.
2. Use the ~/.Xauthority file of the user who started the X11
session. This can only be done by root or a sufficiently
privileged user, and it works like this:
$ su -
Password: ****
After you have gained superuser privileges, you can `merge' the
proper credentials that will allow you to connect to the running
X11 session (even though it wasn't `root' that started it), by
using xauth(1):
csh# setenv DISPLAY localhost:0
csh# xauth merge ~user/.Xauthority
Now you should be allowed to run X11 programs just fine.
I did that and it worked! I stopped and started Xorg and the changes seem to be permanent.
Now I don't have to use the "xhost +localhost" and "setenv DISPLAY localhost:0.0" any more.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
However, non X type programs like vi start ok without errors
That's normal.
On 2006-02-23 10:23, Rob <rob@xxxxxxxxxxxx> wrote:
I guess my next step will be to add the host "xenon" to /etc/hosts. Then it
looks like this:
::1 localhost xenon
127.0.0.1 localhost xenon
Is that correct?
This is exactly what I've been trying to say all along! :)
Yes, please *do* that.
- Giorgos
Thank you very much Giorgos for your help! I appreciate it very much. I still have to get sendmail
starting at bootup but I can do that another day. Tomorrow I am moving so my internet access might
be down for a couple of days anyway. I am going to take a rest! I will copy the list
on this one just in case someone else runs into the same problem. Or maybe I could write something up
that could be in some document. When you go through the learning experience it is very easy at that
time to explain how you fixed something- although I have to admit that I am still somewhat uncertain
how all of it works. I will read the man pages carefully for anything related to what we have just
done.
I also found something else out. Regarding my original problem of not being able to run an X type
program off of the xterm command line as user- it turns out that some other programs started up fine. The
difference is that the "animabob" program that I was trying to start uses OpenGL. I grepped through
the "animabob" source and found the OpenGL call where "out of display lists" originates:
The routine reads:
base = glGenLists((GLuint) last+1);
if (base == 0) {
printf ("out of display lists")
exit (0):
}
I tried several OpenGL based games like apoolGL and gleyes and they work fine. So really maybe it is not
an OpenGL problem or just a problem in how the "animabob" program implements OpenGL. I have compiled this
program outside the ports system long ago and it worked fine from the command line, so I am not sure what
has happened over the intervening time.
Thanks again.
Sincerely,
Rob Lytle
--
-----------------------
http://www.roblytle.org
Rob Lytle Home Page
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: problem regarding setting DISPLAY env variable and hostname
- From: Giorgos Keramidas
- Re: problem regarding setting DISPLAY env variable and hostname
- References:
- Re: problem regarding setting DISPLAY env variable and hostname
- From: Rob
- Re: problem regarding setting DISPLAY env variable and hostname
- From: Giorgos Keramidas
- Re: problem regarding setting DISPLAY env variable and hostname
- From: Giorgos Keramidas
- Re: problem regarding setting DISPLAY env variable and hostname
- Prev by Date: Re: problem regarding setting DISPLAY env variable and hostname
- Next by Date: Re: problem regarding setting DISPLAY env variable and hostname
- Previous by thread: Re: problem regarding setting DISPLAY env variable and hostname
- Next by thread: Re: problem regarding setting DISPLAY env variable and hostname
- Index(es):
Relevant Pages
|
