bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Philipp Stephani]

This is unfortunately a bit hard to reproduce and probably depends on
details of the system.  However, the following steps work for me:

1. emacs -Q -l server -eval '(setq server-name "/tmp/emacs.sock")' -f server-start

2. SSH into some remote machine and forward the socket:

   ssh -R /tmp/emacs.sock:/tmp/emacs.sock REMOTE_HOST

3. On the remote machine:

   emacsclient -T "/ssh:$HOSTNAME:/" -s /tmp/emacs.sock --create-frame FILENAME

At least on my setup, no frame is created on the first machine.


In GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0)
 of 2020-04-24
Repository revision: 85fb94273375fe793ced4404ade6392e38b4c381
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux rodete

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --enable-gtk-deprecation-warnings --with-modules
 --without-pop --with-mailutils --enable-gcc-warnings=warn-only
 CFLAGS=-O3 LDFLAGS=-O3'

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
XDBE XIM MODULES THREADS PDUMPER GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec epa epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton
derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars mailcap subr-x rx gnutls puny seq
byte-opt gv bytecomp byte-compile cconv dbus xml cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 63639 4885)
 (symbols 48 8451 1)
 (strings 32 22359 1976)
 (string-bytes 1 709828)
 (vectors 16 12526)
 (vector-slots 8 175244 8438)
 (floats 8 25 29)
 (intervals 56 202 0)
 (buffers 992 11))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

If you received this communication by mistake, please don’t forward it to
anyone else (it may contain confidential or privileged information), please
erase all copies of it, including all attachments, and please let the sender
know it went to the wrong person.  Thanks.

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 22:48:17 +0200, Philipp Stephani <p.stephani2@gmail.com> said:

    Philipp> This is unfortunately a bit hard to reproduce and probably depends on
    Philipp> details of the system.  However, the following steps work for me:

    Philipp> 1. emacs -Q -l server -eval '(setq server-name "/tmp/emacs.sock")' -f server-start

    Philipp> 2. SSH into some remote machine and forward the socket:

    Philipp>    ssh -R /tmp/emacs.sock:/tmp/emacs.sock REMOTE_HOST

    Philipp> 3. On the remote machine:

    Philipp>    emacsclient -T "/ssh:$HOSTNAME:/" -s /tmp/emacs.sock --create-frame FILENAME

    Philipp> At least on my setup, no frame is created on the first machine.

'--create-frame' attempts to create a graphical frame, as far as I
know. Does '-t' work instead?

(frankly Iʼm amazed any of this even vaguely works over ssh forwarded
local sockets :-))

Roobert

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>     Philipp> 3. On the remote machine:
>
>     Philipp>    emacsclient -T "/ssh:$HOSTNAME:/" -s /tmp/emacs.sock
>     Philipp> --create-frame FILENAME
>
>     Philipp> At least on my setup, no frame is created on the first machine.
>
> '--create-frame' attempts to create a graphical frame, as far as I
> know. Does '-t' work instead?

But isn't the bug report about not being able to create graphical
frames?  I'd assume -t would work fine...

> (frankly Iʼm amazed any of this even vaguely works over ssh forwarded
> local sockets :-))

Me too.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Robert Pluim]

>>>>> On Thu, 28 Jan 2021 07:50:50 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    Philipp> 3. On the remote machine:
    >> 
    Philipp> emacsclient -T "/ssh:$HOSTNAME:/" -s /tmp/emacs.sock
    Philipp> --create-frame FILENAME
    >> 
    Philipp> At least on my setup, no frame is created on the first machine.
    >> 
    >> '--create-frame' attempts to create a graphical frame, as far as I
    >> know. Does '-t' work instead?

    Lars> But isn't the bug report about not being able to create graphical
    Lars> frames?  I'd assume -t would work fine...

Where's the X connection that emacs would use to create the graphical
frame? Itʼs the emacs server socket thatʼs been forwarded.

Robert

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Where's the X connection that emacs would use to create the graphical
> frame? Itʼs the emacs server socket thatʼs been forwarded.

Yes, but the Emacs daemon and the display were both on machine 1, so
the display wouldn't need to be forwarded?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Philipp Stephani]

Am Do., 28. Jan. 2021 um 09:21 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Robert Pluim <rpluim@gmail.com> writes:
>
> > Where's the X connection that emacs would use to create the graphical
> > frame? Itʼs the emacs server socket thatʼs been forwarded.
>
> Yes, but the Emacs daemon and the display were both on machine 1, so
> the display wouldn't need to be forwarded?
>

Correct, there's no X forwarding in the loop here.

emacsclient -t also doesn't work right: It reuses an existing
graphical frame on the first machine, rather than creating a new TTY
frame, and it prints internal TRAMP status messages into the file
buffer.

emacsclient without either --create-frame or -t works fine (but
doesn't create a frame).

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Robert Pluim]

>>>>> On Thu, 28 Jan 2021 09:42:57 +0100, Philipp Stephani <p.stephani2@gmail.com> said:

    Philipp> Am Do., 28. Jan. 2021 um 09:21 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
    >> 
    >> Robert Pluim <rpluim@gmail.com> writes:
    >> 
    >> > Where's the X connection that emacs would use to create the graphical
    >> > frame? Itʼs the emacs server socket thatʼs been forwarded.
    >> 
    >> Yes, but the Emacs daemon and the display were both on machine 1, so
    >> the display wouldn't need to be forwarded?
    >> 

Yes, I was confused.

    Philipp> Correct, there's no X forwarding in the loop here.

    Philipp> emacsclient -t also doesn't work right: It reuses an existing
    Philipp> graphical frame on the first machine, rather than creating a new TTY
    Philipp> frame, and it prints internal TRAMP status messages into the file
    Philipp> buffer.

    Philipp> emacsclient without either --create-frame or -t works fine (but
    Philipp> doesn't create a frame).

It all works fine for me, with one important caveat: I only have one
Linux machine, so Iʼm ssh'ing back to myself. Iʼll see if I can rustle
up a second one in the cloud somewhere.

It fails for me when the remote machine is macOS with

*ERROR*: Could not open file: /dev/ttys005

but I think thatʼs a different bug.

BTW, have you tried doing this with tcp sockets rather than ssh
forwarded ones?

Robert

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Philipp]

> Am 28.01.2021 um 10:43 schrieb Robert Pluim <rpluim@gmail.com>:
> 
>>>>>> On Thu, 28 Jan 2021 09:42:57 +0100, Philipp Stephani <p.stephani2@gmail.com> said:
> 
>    Philipp> Am Do., 28. Jan. 2021 um 09:21 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>>> 
>>> Robert Pluim <rpluim@gmail.com> writes:
>>> 
>>>> Where's the X connection that emacs would use to create the graphical
>>>> frame? Itʼs the emacs server socket thatʼs been forwarded.
>>> 
>>> Yes, but the Emacs daemon and the display were both on machine 1, so
>>> the display wouldn't need to be forwarded?
>>> 
> 
> Yes, I was confused.
> 
>    Philipp> Correct, there's no X forwarding in the loop here.
> 
>    Philipp> emacsclient -t also doesn't work right: It reuses an existing
>    Philipp> graphical frame on the first machine, rather than creating a new TTY
>    Philipp> frame, and it prints internal TRAMP status messages into the file
>    Philipp> buffer.
> 
>    Philipp> emacsclient without either --create-frame or -t works fine (but
>    Philipp> doesn't create a frame).
> 
> It all works fine for me, with one important caveat: I only have one
> Linux machine, so Iʼm ssh'ing back to myself. Iʼll see if I can rustle
> up a second one in the cloud somewhere.

Thanks!

> 
> It fails for me when the remote machine is macOS with
> 
> *ERROR*: Could not open file: /dev/ttys005
> 
> but I think thatʼs a different bug.

Indeed, but probably also one worth reporting.

> 
> BTW, have you tried doing this with tcp sockets rather than ssh
> forwarded ones?
> 

Not really (AFAIK there’s no way to secure them).

bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Robert Pluim]

>>>>> On Sun, 31 Jan 2021 20:43:53 +0100, Philipp <p.stephani2@gmail.com> said:

    Philipp> emacsclient -t also doesn't work right: It reuses an existing
    Philipp> graphical frame on the first machine, rather than creating a new TTY
    Philipp> frame, and it prints internal TRAMP status messages into the file
    Philipp> buffer.
    >> 
    Philipp> emacsclient without either --create-frame or -t works fine (but
    Philipp> doesn't create a frame).
    >> 
    >> It all works fine for me, with one important caveat: I only have one
    >> Linux machine, so Iʼm ssh'ing back to myself. Iʼll see if I can rustle
    >> up a second one in the cloud somewhere.

    Philipp> Thanks!

So I found one, and I see the same issues, although I donʼt get Tramp
status messages in the buffer, but what looks like terminal control
codes.

    >> 
    >> It fails for me when the remote machine is macOS with
    >> 
    >> *ERROR*: Could not open file: /dev/ttys005
    >> 
    >> but I think thatʼs a different bug.

    Philipp> Indeed, but probably also one worth reporting.

Because of (reasons) Iʼm not too enthusiastic about reporting and
debugging issues involving macOS.

    >> 
    >> BTW, have you tried doing this with tcp sockets rather than ssh
    >> forwarded ones?
    >> 

    Philipp> Not really (AFAIK there’s no way to secure them).

Depends what you mean by secure them. You can instruct server.el to
listen on a tcp socket on localhost, and forward that using ssh. The
server file contains an auth cookie that you'd need to copy to the
remote host.

Anyway, Iʼve just tried it, and the failures are the same. I guess
Someone™ needs to step through server.el to figure out what's going on.

Robert