Failed to run Emacs in X windows mode on remote host over ssh with X11 forwarding enabled.

hongy...@gmail.com

unread,

Jul 27, 2021, 9:30:51 AM7/27/21

to

On LAN, I'm trying to run Emacs on another machine, as shown below:

$ ssh -X wer...@192.168.10.100
$ emacs

At this moment, I noticed the following information:

Display localhost:10.0 unavailable, simulating -nw

As a result, Emacs will run in console mode and can't be able to
communicate with X.

Any hints for solving this problem?

Regards,
HY

Grant Taylor

unread,

Jul 27, 2021, 2:33:54 PM7/27/21

to

On 7/27/21 7:30 AM, hongy...@gmail.com wrote:
> Any hints for solving this problem?

What is the DISPLAY environment variable set to?

Do any X11 programs work through SSH?

--
Grant. . . .
unix || die

David W. Hodgins

unread,

Jul 27, 2021, 3:34:45 PM7/27/21

to

On the system you're connected to, in /etc/ssh/sshd_config is the config set to ...
X11Forwarding yes

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

Keith Thompson

Display localhost:10.0 unavailable, simulating -nw

HY

Keith Thompson

unread,

Jul 27, 2021, 10:04:46 PM7/27/21

to

"hongy...@gmail.com" <hongy...@gmail.com> writes:
> On Wednesday, July 28, 2021 at 2:33:54 AM UTC+8, Grant Taylor wrote:
>> On 7/27/21 7:30 AM, hongy...@gmail.com wrote:
>> > Any hints for solving this problem?
>> What is the DISPLAY environment variable set to?
>
> On server side:
>
> werner@X10DAi:~$ echo $DISPLAY
> :1
>
> On client side, it's empty:
>
> $ echo $DISPLAY
>
> $

That seems inconsistent with your original post. You said you got this
message from emacs:

Display localhost:10.0 unavailable, simulating -nw

which strongly implies that $DISPLAY was set to "localhost:10.0", at
least in your emacs process.

Try `echo $DISPLAY` and `emacs` from the same shell process. If you get
an empty string from the first (it's more likely that $DISPLAY is not
set than that it's set to the empty string) and "Display localhost:10.0
unavailable, simulating -nw" from emacs, then something very strange is
going on.

What does `env | grep '^DISPLAY='` print?

Keith Thompson

unread,

Jul 27, 2021, 10:06:42 PM7/27/21

to

"hongy...@gmail.com" <hongy...@gmail.com> writes:
> On Wednesday, July 28, 2021 at 3:58:13 AM UTC+8, Keith Thompson wrote:
>> "hongy...@gmail.com" <hongy...@gmail.com> writes:
>> > On LAN, I'm trying to run Emacs on another machine, as shown below:
>> >
>> > $ ssh -X wer...@192.168.10.100
>> > $ emacs
>> >
>> > At this moment, I noticed the following information:
>> >
>> > Display localhost:10.0 unavailable, simulating -nw
>> >
>> > As a result, Emacs will run in console mode and can't be able to
>> > communicate with X.
>> >
>> > Any hints for solving this problem?
>> Apparently $DISPLAY is being set to "localhost:10.0", which is typical.
>>
>> This is unlikely to be specific to emacs. I presume other X client
>> programs fail similarly, but to verify try running "xlogo" or "xclock".
>
> Both "xlogo" and "xclock" run correctly.
>
>> Try running "xdpyinfo". (Warning: It produces several thousand lines of
>> output on my system).
>
> werner@X10DAi:~$ xdpyinfo
> name of display: localhost:10.0
> version number: 11.0
> vendor string: The X.Org Foundation

[993 lines deleted]

I guess I should have said that we don't need to see all the output.
It was basically a test to see whether the display is there.

>> It's possible that "ssh -Y" would avoid the problem. It's worth trying,
>> but be sure to read the documentation, since it bypasses some security
>> checks. (It might be acceptable if the LAN is entirely under your
>> control, though others might disagree with that.)
>
> I tried with:
>
> $ ssh -Y wer...@192.168.10.100
>
> But still meet the following msg:
>
> werner@X10DAi:~$ emacs
> Display localhost:10.0 unavailable, simulating -nw

hongy...@gmail.com

unread,

Jul 27, 2021, 10:07:19 PM7/27/21

to

On Wednesday, July 28, 2021 at 9:41:01 AM UTC+8, Grant Taylor wrote:
> On 7/27/21 7:32 PM, hongy...@gmail.com wrote:
> > On server side:
> >
> > werner@X10DAi:~$ echo $DISPLAY
> > :1
> Did you run that from your SSH connection? Or directly on the server?

Directly on the server:

werner@X10DAi:~$ echo $DISPLAY
:1

From the SSH connection

werner@X10DAi:~$ echo $DISPLAY
localhost:10.0

> :1 /may/ be okay for a remote connection. But it may also be a
> reference to a local / physical display on the server.
> > On client side, it's empty:
> >
> > $ echo $DISPLAY
> I would have expected the client to have a DISPLAY variable set.
> ESPECIALLY if running it form in a GUI terminal emulator.
> > I run ssh in verbose mode (-v):
> Verbose mode shouldn't change the behavior of X11 forwarding. But it
> will give more information.
> > Then xterm also fails to open display, and it says that X11 connection
> > rejected because of wrong authentication.
> Okay. That's sort of what I was expecting.
>
> You can use the 'xhost' command to allow other clients to connect
> bypassing the ~/.Xauthority (?) cooky. E.g.
>
> xhost +192.0.2.1
>
> That should allow 192.0.2.1 to connect to your local X11 display.
>
> N.B. You can remove the IP and just use "+" to allow all IPs to connect
> too.

Thanks. I've run the `xhost +' on server side now:

werner@X10DAi:~$ xhost +
access control disabled, clients can connect from any host

> Use the following command to remove permission:
>
> xhost -
>
> N.B. My understanding is that the xhost permissions are non-persistent.
> > I've enabled the following options on server and client sides:
> That means that OpenSSH is configured to allow X11 forwarding.
>
> As Keith mentioned, the "-Y" option may help.

Now, I connect to the server with the following setting:

$ ssh -Y wer...@192.168.10.100

The testing results:

Xterm works, but Emacs still report the same problem.

HY

hongy...@gmail.com

unread,

Jul 27, 2021, 10:18:59 PM7/27/21

to

On Wednesday, July 28, 2021 at 10:04:46 AM UTC+8, Keith Thompson wrote:
> "hongy...@gmail.com" <hongy...@gmail.com> writes:
> > On Wednesday, July 28, 2021 at 2:33:54 AM UTC+8, Grant Taylor wrote:
> >> On 7/27/21 7:30 AM, hongy...@gmail.com wrote:
> >> > Any hints for solving this problem?
> >> What is the DISPLAY environment variable set to?
> >
> > On server side:
> >
> > werner@X10DAi:~$ echo $DISPLAY
> > :1
> >
> > On client side, it's empty:
> >
> > $ echo $DISPLAY
> >
> > $
> That seems inconsistent with your original post. You said you got this
> message from emacs:
> Display localhost:10.0 unavailable, simulating -nw
> which strongly implies that $DISPLAY was set to "localhost:10.0", at
> least in your emacs process.
>
> Try `echo $DISPLAY` and `emacs` from the same shell process. If you get
> an empty string from the first (it's more likely that $DISPLAY is not
> set than that it's set to the empty string) and "Display localhost:10.0
> unavailable, simulating -nw" from emacs, then something very strange is
> going on.
>
> What does `env | grep '^DISPLAY='` print?

Sorry for my unclear description to some extent, especially on the network topology used by the testing in question. I restate the network topology below:

The ssh server: 192.168.10.100
The ssh client: 192.168.10.101

But the ssh client in my situation is a virtual machine running within Proxmox VE, so I must ssh into it first for doing the testing discussed here.

If I ssh to the client like the following:

$ ssh wer...@192.168.10.101
$ env | grep '^DISPLAY='
$

If with the following option:

$ ssh -Y wer...@192.168.10.101
$ env | grep '^DISPLAY='
DISPLAY=localhost:10.0

HY

David W. Hodgins

unread,

Jul 27, 2021, 11:49:11 PM7/27/21

to

Got emacs to work in gui mode under ssh.

Try running "ssh -X -Y wer...@192.168.10.101"
then running emacs.

David W. Hodgins

unread,

Jul 27, 2021, 11:49:12 PM7/27/21

to

On Tue, 27 Jul 2021 22:07:16 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:
> Xterm works, but Emacs still report the same problem.

In that case stop looking at X or ssh settings. It's a problem with emacs, not
the ssh or X setup.

The man page for emacs has a section for running it under X. It's not a program
I use or am familiar with.

If no one else here has an idea, please open a bug report for emacs. Perhaps
it's package maintainer will have an idea.

David W. Hodgins

unread,

Jul 27, 2021, 11:49:12 PM7/27/21

to

On Tue, 27 Jul 2021 22:18:56 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:

> Sorry for my unclear description to some extent, especially on the network topology used by the testing in question. I restate the network topology below:
>
> The ssh server: 192.168.10.100
> The ssh client: 192.168.10.101
>
> But the ssh client in my situation is a virtual machine running within Proxmox VE, so I must ssh into it first for doing the testing discussed here.
>
> If I ssh to the client like the following:
>
> $ ssh wer...@192.168.10.101
> $ env | grep '^DISPLAY='
> $
>
> If with the following option:
>
> $ ssh -Y wer...@192.168.10.101
> $ env | grep '^DISPLAY='
> DISPLAY=localhost:10.0

One point that is often misunderstood. When discussing X, the server is the one
that's physically connected to the monitor. The gui programs you run on the
system you're connecting to via ssh become clients of the X server running on
the machine you're connecting from.

I partially figure out how to get it working. After connecting via ssh to the
remote system, run "DISPLAY= emacs". It works, but runs emacs in text mode
instead of gui mode.

hongy...@gmail.com

unread,

Jul 28, 2021, 12:12:57 AM7/28/21

to

I tried the above from the server side itself:

$ ssh -XY wer...@192.168.10.100

Then run emacs, but encounter the same message:

$ emacs

unread,

Jul 28, 2021, 1:51:23 AM7/28/21

to

I'm out of ideas. I know it's working for me, so it's not a Mageia bug, just
something different about that setup. Hopefully someone else here will figure
it out.

hongy...@gmail.com

unread,

Jul 28, 2021, 3:02:38 AM7/28/21

to

On Wednesday, July 28, 2021 at 1:51:23 PM UTC+8, David W. Hodgins wrote:
> On Wed, 28 Jul 2021 01:25:04 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:
>
> > On Wednesday, July 28, 2021 at 1:21:28 PM UTC+8, David W. Hodgins wrote:
> >> On Wed, 28 Jul 2021 00:12:54 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:
> >> > I tried the above from the server side itself:
> >> >
> >> > $ ssh -XY wer...@192.168.10.100
> >> >
> >> > Then run emacs, but encounter the same message:
> >> >
> >> > $ emacs
> >> > Display localhost:10.0 unavailable, simulating -nw
> >> Strange. Try ...
> >> $ ssh -XY wer...@192.168.10.100
> >> $ DISPLAY=:0 emacs
> >
> > werner@X10DAi:~$ DISPLAY=:0 emacs
> > No protocol specified
> > Display :0 unavailable, simulating -nw
> I'm out of ideas. I know it's working for me, so it's not a Mageia bug, just
> something different about that setup. Hopefully someone else here will figure
> it out.

Got it. To be sure, your method is right, but I happened to use an error value of "$DISPLAY". Here, I summarize the successful methods as follows:

Obtain the value of `$DISPLAY' locally on the ssh server:

$ echo $DISPLAY
:1

Then all the following methods will do the trick:

Method 1:

$ ssh -X -f wer...@192.168.10.100 DISPLAY=:1 emacs
or
$ ssh -X -f wer...@192.168.10.100 env DISPLAY=:1 emacs

Method 2:

$ ssh -X wer...@192.168.10.100

Then run any of the following commands:

$ DISPLAY=:1 emacs
$ env DISPLAY=:1 emacs
$ emacs -d :1
$ emacs --display :1

NB.

[1]. I obtain the clues from here: <https://kb.iu.edu/d/acxu>
[2]. X server relevant options supplied by Emacs:

werner@X10DAi:~$ man emacs|grep -A 4 -- '-d '
-d displayname, --display=displayname
Create the Emacs window on the display specified by dis‐
playname. Must be the first option specified in the com‐
mand line.

werner@X10DAi:~$ emacs --help|grep -- '-d '
--display, -d DISPLAY use X server DISPLAY

Regards,
HY

hongy...@gmail.com

unread,

Jul 28, 2021, 3:36:18 AM7/28/21

to

On Wednesday, July 28, 2021 at 3:02:38 PM UTC+8, hongy...@gmail.com wrote:
> On Wednesday, July 28, 2021 at 1:51:23 PM UTC+8, David W. Hodgins wrote:
> > On Wed, 28 Jul 2021 01:25:04 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:
> >
> > > On Wednesday, July 28, 2021 at 1:21:28 PM UTC+8, David W. Hodgins wrote:
> > >> On Wed, 28 Jul 2021 00:12:54 -0400, hongy...@gmail.com <hongy...@gmail.com> wrote:
> > >> > I tried the above from the server side itself:
> > >> >
> > >> > $ ssh -XY wer...@192.168.10.100
> > >> >
> > >> > Then run emacs, but encounter the same message:
> > >> >
> > >> > $ emacs
> > >> > Display localhost:10.0 unavailable, simulating -nw
> > >> Strange. Try ...
> > >> $ ssh -XY wer...@192.168.10.100
> > >> $ DISPLAY=:0 emacs
> > >
> > > werner@X10DAi:~$ DISPLAY=:0 emacs
> > > No protocol specified
> > > Display :0 unavailable, simulating -nw
> > I'm out of ideas. I know it's working for me, so it's not a Mageia bug, just
> > something different about that setup. Hopefully someone else here will figure
> > it out.
> Got it. To be sure, your method is right, but I happened to use an error value of "$DISPLAY". Here, I summarize the successful methods as follows:
>
> Obtain the value of `$DISPLAY' locally on the ssh server:
>
> $ echo $DISPLAY
> :1

Or use the following method:

$ xdpyinfo | grep -i display
name of display: :1

hongy...@gmail.com

unread,

Jul 28, 2021, 8:45:29 AM7/28/21

to

Another issue: how to obtain the correct value of the above variable from within the ssh client instead of locally logged into the machine?

HY

Keith Thompson

unread,

Jul 28, 2021, 10:24:45 AM7/28/21

to

"hongy...@gmail.com" <hongy...@gmail.com> writes:
[...]

>> Got it. To be sure, your method is right, but I happened to use an
>> error value of "$DISPLAY". Here, I summarize the successful methods
>> as follows:
>>
>> Obtain the value of `$DISPLAY' locally on the ssh server:
>>
>> $ echo $DISPLAY
>> :1
>
> Or use the following method:
>
> $ xdpyinfo | grep -i display
> name of display: :1

That seems pointless. xdpyinfo gets the value to show by looking at
$DISPLAY. (I had suggested running xdpyinfo just to see whether it
succeeds or fails.)

hongy...@gmail.com

unread,

Jul 28, 2021, 10:51:04 PM7/28/21

to

On Wednesday, July 28, 2021 at 10:24:45 PM UTC+8, Keith Thompson wrote:
> "hongy...@gmail.com" <hongy...@gmail.com> writes:
> [...]
> >> Got it. To be sure, your method is right, but I happened to use an
> >> error value of "$DISPLAY". Here, I summarize the successful methods
> >> as follows:
> >>
> >> Obtain the value of `$DISPLAY' locally on the ssh server:
> >>
> >> $ echo $DISPLAY
> >> :1
> >
> > Or use the following method:
> >
> > $ xdpyinfo | grep -i display
> > name of display: :1
> That seems pointless. xdpyinfo gets the value to show by looking at
> $DISPLAY. (I had suggested running xdpyinfo just to see whether it
> succeeds or fails.)

Then, where does $DISPLAY come from?

HY

Janis Papanagnou

unread,

Jul 28, 2021, 10:56:31 PM7/28/21

to

From the environment. (As the man page also tells you.)

Janis

> HY
>

Keith Thompson

unread,

Jul 29, 2021, 12:50:12 AM7/29/21

to

It's an environment variable, of course. It's set by sshd (if X
forwarding is enabled) and inherited by your shell, or it's set by
whatever invokes your terminal emulator if you launch it on the system
itself, or by anything else that sets it.

emacs displays the message

Display localhost:10.0 unavailable, simulating -nw

if and only if XOpenDisplay("localhost:10.0") returns a null pointer.

Is it correct that running `emacs` displays that error message and
running `xlogo` *from the same shell process* successfully displays a
window with the X logo? (Please verify before answering.) If so, then
something weird is going on. I don't know why xlogo's call to
XOpenDisplay would succeed while emacs's call would fail. If that is
what's happening, try running emacs followed by xlogo, and xlogo
followed by emacs.

I suggest setting PS1 to some unique value so you can be sure you're
running all the commands from the same shell process. (Since you're
ssh'ing from one system to another, it's conceivable that you could
return to another shell without noticing it if the prompt never
changes.)

It's odd that in your original article your $DISPLAY was
"localhost:10.0" and in later followups it's ":1". I haven't followed
all the details.

hongy...@gmail.com

unread,

Jul 29, 2021, 5:05:16 AM7/29/21

to

Thank you for your explanation. I found the following option of sshd_config:

$ man sshd_config |egrep -A4 '^[ ]*X11DisplayOffset$'
X11DisplayOffset
Specifies the first display number available for sshd(8)'s X11 for‐
warding. This prevents sshd from interfering with real X11 servers.
The default is 10.

> Is it correct that running `emacs` displays that error message and
> running `xlogo` *from the same shell process* successfully displays a
> window with the X logo? (Please verify before answering.)

Yes.

> If so, then something weird is going on. I don't know why xlogo's call to
> XOpenDisplay would succeed while emacs's call would fail. If that is
> what's happening, try running emacs followed by xlogo, and xlogo
> followed by emacs.

Same results observed.

> I suggest setting PS1 to some unique value so you can be sure you're
> running all the commands from the same shell process. (Since you're
> ssh'ing from one system to another, it's conceivable that you could
> return to another shell without noticing it if the prompt never
> changes.)

Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.

> It's odd that in your original article your $DISPLAY was
> "localhost:10.0" and in later followups it's ":1". I haven't followed
> all the details.

If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
"localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

HY

Peter van Hooft

unread,

Jul 29, 2021, 5:30:06 AM7/29/21

to

On 2021-07-29, Keith Thompson <Keith.S.T...@gmail.com> wrote:
>
> I suggest setting PS1 to some unique value so you can be sure you're
> running all the commands from the same shell process. (Since you're
> ssh'ing from one system to another, it's conceivable that you could
> return to another shell without noticing it if the prompt never
> changes.)

*this*

>
> It's odd that in your original article your $DISPLAY was
> "localhost:10.0" and in later followups it's ":1". I haven't followed
> all the details.
>

A common pitfall is that xauth hasn't been installed on the ssh server,
so you may want to check that (which xauth).

Peter

William Unruh

unread,

Jul 29, 2021, 10:01:11 AM7/29/21

to

On 2021-07-29, hongy...@gmail.com <hongy...@gmail.com> wrote:
....

>
>> It's odd that in your original article your $DISPLAY was
>> "localhost:10.0" and in later followups it's ":1". I haven't followed
>> all the details.
>
> If I logged in to the ssh server from the noVNC console of vitrual machine running in pve, the $DISPLAY value will be
> "localhost:10.0"; if I locally check the variable's value on the ssh server, it will be ":1".

Not sure what you are saying but that sounds as it should be. The
display on the machine itself should be :1 (or whatever you logged in
as) while the display into the ssh from a remote machine should be :10.
Different X displays, different numbers. Imagine it is not a virtual
machine but is a different physical machine. One is "put the X stuff
onto the local screen" and the other one is "put the X stuff onto the
screen of the system which sshed into me"
That both screens are the actually the same physical piece of hardware is
irrelevant.
>
> HY

hongy...@gmail.com

unread,

Jul 29, 2021, 8:50:17 PM7/29/21

to

On Thursday, July 29, 2021 at 5:30:06 PM UTC+8, Peter van Hooft wrote:
> On 2021-07-29, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> >
> > I suggest setting PS1 to some unique value so you can be sure you're
> > running all the commands from the same shell process. (Since you're
> > ssh'ing from one system to another, it's conceivable that you could
> > return to another shell without noticing it if the prompt never
> > changes.)
> *this*

What's your meaning by saying the above word?

> >
> > It's odd that in your original article your $DISPLAY was
> > "localhost:10.0" and in later followups it's ":1". I haven't followed
> > all the details.
> >
> A common pitfall is that xauth hasn't been installed on the ssh server,
> so you may want to check that (which xauth).

Yes, see below:

werner@X10DAi:~$ which xauth
/usr/bin/xauth

HY

Grant Taylor

unread,

Jul 29, 2021, 9:00:59 PM7/29/21

to

On 7/27/21 8:07 PM, hongy...@gmail.com wrote:
> Xterm works, but Emacs still report the same problem.

unread,

Jul 29, 2021, 11:45:13 PM7/29/21

to

On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:
> On 7/27/21 8:07 PM, hongy...@gmail.com wrote:
> > Xterm works, but Emacs still report the same problem.
> I'm starting to question the "emacs" command.
>
> Please do a "which emacs" and then "file /path/to/emacs" to see what
> type of file emacs is.
>
> I'm wondering if it's by chance a script that's artificially changing /
> overriding the DISPLAY environment variable.

I use a self-written wrapper script to start Emacs, but I really haven't overridden the DISPLAY environment variable in the script. See the following for more detailed info:

$ which emacs
/home/werner/.local/bin/emacs

$ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#'
script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

HY

hongy...@gmail.com

unread,

Jul 29, 2021, 11:49:43 PM7/29/21

to

On Friday, July 30, 2021 at 10:50:56 AM UTC+8, Keith Thompson wrote:
> Grant Taylor <gta...@tnetconsulting.net> writes:
> > On 7/27/21 8:07 PM, hongy...@gmail.com wrote:
> >> Xterm works, but Emacs still report the same problem.
> >
> > I'm starting to question the "emacs" command.
> >
> > Please do a "which emacs" and then "file /path/to/emacs" to see what
> > type of file emacs is.
> I suggest "type emacs" rather than "which emacs".

$ type emacs
emacs is hashed (/home/werner/.local/bin/emacs)

$ type -a emacs
emacs is /home/werner/.local/bin/emacs
emacs is /usr/local/bin/emacs
emacs is /usr/bin/emacs
emacs is /bin/emacs

So, the first entry will be picked by shell, and see the following for more detailed info about the corresponding script:

$ egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#'

script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

Grant Taylor

unread,

Jul 30, 2021, 12:06:09 AM7/30/21

to

On 7/29/21 9:49 PM, hongy...@gmail.com wrote:
> proxychains-ng-socks5 $EMACS "$@"

Why are you running emacs via proxychains?

That's almost definitely going to mess with it's ability to connect to
an X11 server, wherever it is, unless said proxy can communicate with
said X11 server.

Try running /usr/local/bin/emacs and seeing if that works.

Grant Taylor

unread,

Jul 30, 2021, 12:07:25 AM7/30/21

to

On 7/29/21 9:45 PM, hongy...@gmail.com wrote:
> I use a self-written wrapper script to start Emacs, but I really
> haven't overridden the DISPLAY environment variable in the script. See
> the following for more detailed info:

No, you're not altering the DISPLAY environment variable. But you are
quite likely intercepting any and all network connection attempts and
routing them through the configured proxy, including attempts to connect
to the value of $DISPLAY.

Spiros Bousbouras

unread,

Jul 30, 2021, 12:15:34 AM7/30/21

to

On Thu, 29 Jul 2021 17:50:14 -0700 (PDT)
"hongy...@gmail.com" <hongy...@gmail.com> wrote:
> On Thursday, July 29, 2021 at 5:30:06 PM UTC+8, Peter van Hooft wrote:
> > On 2021-07-29, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> > >
> > > I suggest setting PS1 to some unique value so you can be sure you're
> > > running all the commands from the same shell process. (Since you're
> > > ssh'ing from one system to another, it's conceivable that you could
> > > return to another shell without noticing it if the prompt never
> > > changes.)
> > *this*
>
> What's your meaning by saying the above word?

It means he emphatically agrees with Keith Thompson.

hongy...@gmail.com

unread,

Jul 30, 2021, 12:17:19 AM7/30/21

to

Now, on the ssh server, I append the following lines at the bottom of my ~/.bashrc file:

set -o nounset
export PS1="\u@\h pid=$$ \!\$ "

> > $
> >
> > As you can see, the `$DISPLAY' is still empty. Why?
> What is $DISPLAY on the initial system, before you run ssh?

werner@X10DAi pid=1948000 501$ echo $DISPLAY
:1

> What happens when you replace "ssh" by "ssh -X" or "ssh -Y"?

If I don't log in to the ssh server from the pve noVNC console:

$ ssh -X wer...@192.168.10.100
werner@X10DAi pid=2452674 501$ echo $DISPLAY

werner@X10DAi pid=2452674 495$

> X11 forwarding has to be enabled by both the client and the server.
>
> Is $DISPLAY unset or empty? The behavior should be similar either way,
> but it could be helpful to know. Consider `set -o nounset`, at least
> temporarily, so you get an error message referring to an unset variable.
>
> $DISPLAY being either empty or unset is inconsistent with the symptom
> you reported originally, emacs complaining about "localhost:10.0".

If I log in to the ssh server from the pve noVNC console:

$ ssh -X wer...@192.168.10.100
werner@X10DAi pid=1622407 501$ echo $DISPLAY
localhost:10.0
werner@X10DAi pid=1622407 496$

hongy...@gmail.com

unread,

Jul 30, 2021, 12:24:55 AM7/30/21

to

Wonderful analysis, I confirmed the above assertion, as described below:

After I logged in to the ssh server, if the `xlogo' can run correctly, the `/usr/local/bin/emacs', i.e., without using the wrapper script, hence bypassing the proxychains proxy set there, will work with X smoothly.

HY

Spiros Bousbouras

unread,

Jul 30, 2021, 12:25:34 AM7/30/21

to

Unless the comments in the script have some private information you don't want
the world to see or are very long , it would have been better to also show
the comments because they might give some valuable clue. In any case , instead
of

egrep '^[^#]' /home/werner/.local/bin/emacs | grep -v '^[ ]*#'

using
grep -v '^ *#' /home/werner/.local/bin/emacs

does the same job.

Perhaps $HOME/.local/libexec/script_name.sh does something with the DISPLAY
variable. I suggest modifying your script as follows

echo "Point A : the value of DISPLAY is =$DISPLAY="

script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

echo "Point B : the value of DISPLAY is =$DISPLAY="
[ ... Rest the same ...]

I also second the advice to try running emacs directly.

Keith Thompson

unread,

Jul 30, 2021, 12:40:18 AM7/30/21

to

"hongy...@gmail.com" <hongy...@gmail.com> writes:
> On Friday, July 30, 2021 at 9:00:59 AM UTC+8, Grant Taylor wrote:
>> On 7/27/21 8:07 PM, hongy...@gmail.com wrote:
>> > Xterm works, but Emacs still report the same problem.
>> I'm starting to question the "emacs" command.
>>
>> Please do a "which emacs" and then "file /path/to/emacs" to see what
>> type of file emacs is.
>>
>> I'm wondering if it's by chance a script that's artificially changing /
>> overriding the DISPLAY environment variable.
>
> I use a self-written wrapper script to start Emacs, but I really
> haven't overridden the DISPLAY environment variable in the script. See
> the following for more detailed info:

Then the obvious next step is to try the same thing, but running
/usr/bin/emacs directly rather than your wrapper script.

> $ which emacs
> /home/werner/.local/bin/emacs
>
> $ which emacs |xargs egrep '^[^#]'| grep -v '^[ ]*#'
> script_name_sh=$HOME/.local/libexec/script_name.sh
> source $script_name_sh ${BASH_SOURCE[0]}
>
> EMACS=/usr/local/bin/emacs
> if [ -e $EMACS ]; then
> proxychains-ng-socks5 $EMACS "$@"
> fi

Frankly, it should already have occurred to you to try invoking
the emacs executable directly. It's an added layer, and you need
to strip away any such layers while trying to figure out what's causing
the problem. Do the simplest set of steps that reproduces the problem.

Even more obvious than bypassing your wrapper script: Telling us that
you're using one. You should have mentioned that in your original post.
Don't withhold information like that, and don't make us drag it out of
you.

hongy...@gmail.com

unread,

Jul 30, 2021, 12:40:51 AM7/30/21

to

No difference, but thank you for the more concise grep command:
$ grep -v '^ *#' /home/werner/.local/bin/emacs

script_name_sh=$HOME/.local/libexec/script_name.sh
source $script_name_sh ${BASH_SOURCE[0]}

EMACS=/usr/local/bin/emacs
if [ -e $EMACS ]; then
proxychains-ng-socks5 $EMACS "$@"
fi

$

> does the same job.
>
> Perhaps $HOME/.local/libexec/script_name.sh does something with the DISPLAY
> variable. I suggest modifying your script as follows
>
> echo "Point A : the value of DISPLAY is =$DISPLAY="
> script_name_sh=$HOME/.local/libexec/script_name.sh
> source $script_name_sh ${BASH_SOURCE[0]}
> echo "Point B : the value of DISPLAY is =$DISPLAY="
> [ ... Rest the same ...]

werner@X10DAi pid=2452674 483$ emacs
Point A : the value of DISPLAY is ==
Point B : the value of DISPLAY is ==
[...]

Keith Thompson

unread,

Jul 30, 2021, 12:41:55 AM7/30/21

to

That's assuming that /usr/local/bin/emacs is an executable.

You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
check that. Try all three.

hongy...@gmail.com

unread,

Jul 30, 2021, 12:49:14 AM7/30/21

to

On Friday, July 30, 2021 at 12:41:55 PM UTC+8, Keith Thompson wrote:
> Grant Taylor <gta...@tnetconsulting.net> writes:
> > On 7/29/21 9:49 PM, hongy...@gmail.com wrote:
> >> proxychains-ng-socks5 $EMACS "$@"
> >
> > Why are you running emacs via proxychains?
> >
> > That's almost definitely going to mess with it's ability to connect to
> > an X11 server, wherever it is, unless said proxy can communicate with
> > said X11 server.
> >
> > Try running /usr/local/bin/emacs and seeing if that works.
> That's assuming that /usr/local/bin/emacs is an executable.

This is the self-compiled git master version.

> You have /usr/bin/emacs, /bin/emacs, and /usr/local/bin/emacs in your
> path. I'm guessing /usr/bin/emacs and /bin/emacs are the same -- but
> check that. Try all three.

These are the system versions, they are equivalent:

$ realpath -e /usr/bin/emacs
/usr/bin/emacs-nox

$ realpath -e /bin/emacs
/usr/bin/emacs-nox

HY

hongy...@gmail.com

unread,

Jul 30, 2021, 12:52:58 AM7/30/21

to

I didn’t realize this until I got the relevant tips here.

> Don't withhold information like that, and don't make us drag it out of
> you.

TBF, I really omit the fact the X11 communication is also effected by the proxy settings by proxychains.

HY

hongy...@gmail.com

unread,

Jul 30, 2021, 1:03:07 AM7/30/21

to

On Friday, July 30, 2021 at 12:06:09 PM UTC+8, Grant Taylor wrote:
> On 7/29/21 9:49 PM, hongy...@gmail.com wrote:
> > proxychains-ng-socks5 $EMACS "$@"
>
> Why are you running emacs via proxychains?

As far as this problem is concerned, I am in a dilemma: Emacs itself don't support socks5 very well, and I want to install packages from melpa and github repos, which will need socks5 proxy for working smoothly at my location.

> That's almost definitely going to mess with it's ability to connect to
> an X11 server, wherever it is, unless said proxy can communicate with
> said X11 server.

I really have taken it for granted that X11 protocol should work seamlessly with TCP/IP stack and all standard proxy protocols built on it.

> Try running /usr/local/bin/emacs and seeing if that works.

This works, as I've tested later in another thread of this issue.

HY

William Unruh

unread,

Jul 30, 2021, 1:10:23 AM7/30/21

*nod*

So the problem definitely is not with your X11 configuration, but how
you're trying to use it.

Grant Taylor

unread,

Jul 31, 2021, 1:51:15 PM7/31/21

to

On 7/31/21 11:35 AM, Grant Taylor wrote:
> socat immediately comes to mind as providing the ability to listen on an
> IP & port for local connections and translating them to the proper
> SOCKS(5) call to the SOCKS(5) backend.

Another option would be to make sure that the SOCKS(5) proxy can
communicate with your local X11 server.

An external SOCKS(5) proxy will likely have quite a difficult time
communicating with your local X11 server.

You could run a local SOCKS(5) proxy which can conditionally reach your
local X11 server /and/ *chain* to the external SOCKS(5) server you need
to use to access the repos. Think of this as a SOCKS(5) level router
that can pick different routes; local vs chained external SOCKS(5)
proxy, depending on the desired destination.

This is effectively augmenting the communications path that your
existing proxychains-ng-socks5 is using. ;-)

Learn about the problem, understand the problem ~> box, and then think
outside of said box. }:-)

Aside: DANTE has been my go-to SOCKS(5) proxy server for many things.
If DANTE can't provide what I need, I usually turn to parts of BadVPN
and more trickery. Trickery like adding a normal (IP) route via a
tunnel that goes into tun2socks. Tun2socks will then socksify the
traffic it receives from the tunnel interface and send it to the
configured SOCKS server. Thus you can rely on traditional routing to
decide if traffic should go through the SOCKS server or not. }:-D

Kenny McCormack

unread,

Jul 31, 2021, 8:28:54 PM7/31/21

to

In article <se41c8$oeo$1...@tncsrv09.home.tnetconsulting.net>,

Grant Taylor <gta...@tnetconsulting.net> wrote:
>On 7/30/21 12:20 PM, Keith Thompson wrote:
>> My thought was that the word "executable" when used as a noun refers to
>> binary executable file, not a script, but I wasn't sufficiently clear.
>
>You're entitled to your own opinion of what "executable" means.

unread,

Aug 3, 2021, 12:44:03 AM8/3/21

to

On 8/2/21 8:02 PM, hongy...@gmail.com wrote:
> What's the exact meaning of "iLO / RSA / IMM / DRACs" used above?

Uh ... now you're testing my grey matter.

Compaq ~> HP ~> HPE: Integrated Lights Out (card / controller)

IBM: Remote Server Administrator / Integrated Management Module

Dell: Dell Remote Access Controller

While I'm at it, Sun ~> Oracle has System Console / Remote System
Console / Lights Out Manager / Integrated Lights Out Manager / Advanced
Lights Out Manager.

Something like that.

They are all vendor proprietary.

Intelligent Platform Management Interface (?) is the vendor agnostic
(subset) counterpart.

> Thank you for your in-depth explanation.

You're welcome.