problem regarding setting DISPLAY env variable and hostname

[Giorgos Keramidas]

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'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.


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.


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.


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$

Then you have two options:

    1. Start the X11 server in ``listen mode'', which will enable
       connections to port 6000:

            $ startx -listen_tcp

    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.

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