problem regarding setting DISPLAY env variable and hostname

Rob rob at roblytle.org
Thu Feb 23 14:14:02 PST 2006


On Thu, 23 Feb 2006 23:29:47 +0200
Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at roblytle.org> wrote:
> >On Thu, 23 Feb 2006 19:26:28 +0200
> >Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at roblytle.org> wrote:
> >On Thu, 23 Feb 2006 19:26:28 +0200
> >Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at roblytle.org> wrote:
> >On Thu, 23 Feb 2006 19:26:28 +0200
> >Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at roblytle.org> wrote:
> >On Thu, 23 Feb 2006 19:26:28 +0200
> >Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at roblytle.org> 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 at roblytle.org> 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 at flame:/home/keramida$ sockstat -l4 -p 6000
>     USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
>     root     Xorg       876   3  tcp4   *:6000                *:*
>     keramida at flame:/home/keramida$
> 
> If you don't see something like this, but you get an empty port list
> instead, like this one:
> 
>     keramida at flame:/home/keramida$ sockstat -l4 -p 6000
>     USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
>     keramida at 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 at roblytle.org> wrote:
> > However, non X type programs like vi start ok without errors
> 
> That's normal.
> 
> On 2006-02-23 10:23, Rob <rob at roblytle.org> 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


More information about the freebsd-questions mailing list