emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

[Kaushal Modi]

Hello all,

I rebuilt emacs from master today using commit 9a162e2 after about a
month, and was surprised to see that my wrapper bash script that
called "emacsclient -a '' -c&" (two single quote follow that -a
option) no longer works.

Upon running "emacsclient -a '' -c&" directly, I get:

=====
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have
this problem.
Loading paren...
Loading paren...done
Key Chord mode on
Loading /home/kmodi/.emacs.d/elisp/ox-hugo/ox-hugo-autoloads.el (source)...
Loading /home/kmodi/.emacs.d/elisp/ox-hugo/ox-hugo-autoloads.el (source)...done
All backup files will be saved to /tmp/kmodi/.backups/.
Turning on magit-auto-revert-mode...
Turning on magit-auto-revert-mode...done
Starting Emacs daemon.
Restarting server
Emacs daemon should have started, trying to connect again
Waiting for Emacs...
[1]  + Suspended (tty output)        emacsclient -a  -c
=====

On doing fg, I get:

=====
emacsclient -a  -c
Broken pipe
=====

(Looks like those empty single quotes get lost now?)

Well, I get the same result with "emacsclient -c" too.

I am on RHEL 6.8 without sudo access.

I looked at the NEWS but any backward incompatible change wasn't evident.

But looking at https://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=emacsclient,
it looks like some series changes related to emacsclient happened in
the last two weeks.

What debug info can I provide to make emacsclient work once again on my machine?

Thanks.

--
Kaushal Modi

Re: emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Some more information ..

Earlier "emacsclient -c&" used to work. Now doing that auto-suspends that
process and on doing fg, I get "broken pipe".

But "emacsclient -c" seems to be working (without that &). But then I need
to block a new terminal for each new emacsclient invocation (with or
without -c) ..

Also, I fixed a regression in one of the 3rd party Elisp packages that got
updated in last month.

After that, instead of "broken pipe" error, I now see "*ERROR*: Assertion
failed: (eq (match-end 0) (length string))"

That error is originating from servel.el:

=====
  (condition-case err
      (progn
(server-add-client proc)
;; Send our pid
(server-send-string proc (concat "-emacs-pid "
(number-to-string (emacs-pid)) "\n"))
(if (not (string-match "\n" string))
            ;; Save for later any partial line that remains.
            (when (> (length string) 0)
              (process-put proc 'previous-string string))

          ;; In earlier versions of server.el (where we used an
`emacsserver'
          ;; process), there could be multiple lines.  Nowadays this is not
          ;; supported any more.
          (cl-assert (eq (match-end 0) (length string)))
=====

I get that assertion error if I do "emacsclient -c&". But if I do just
"emacsclient -c", a new Emacsclient frame launches fine.

[-- Attachment #2: Type: text/html, Size: 1655 bytes --]

Re: emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

[Kaushal Modi]

These issues go away if I rebuild emacs using the 9-day old commit
f3328f995ee316cffa1a86117e6da2ba299d2c90 [1], before any of the
changes happened to emacsclient.c.

[1]: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f3328f995ee316cffa1a86117e6da2ba299d2c90

--
Kaushal Modi

On Wed, Dec 5, 2018 at 12:36 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:
>
> Some more information ..
>
> Earlier "emacsclient -c&" used to work. Now doing that auto-suspends that process and on doing fg, I get "broken pipe".
>
> But "emacsclient -c" seems to be working (without that &). But then I need to block a new terminal for each new emacsclient invocation (with or without -c) ..
>
> Also, I fixed a regression in one of the 3rd party Elisp packages that got updated in last month.
>
> After that, instead of "broken pipe" error, I now see "*ERROR*: Assertion failed: (eq (match-end 0) (length string))"
>
> That error is originating from servel.el:
>
> =====
>   (condition-case err
>       (progn
> (server-add-client proc)
> ;; Send our pid
> (server-send-string proc (concat "-emacs-pid "
> (number-to-string (emacs-pid)) "\n"))
> (if (not (string-match "\n" string))
>             ;; Save for later any partial line that remains.
>             (when (> (length string) 0)
>               (process-put proc 'previous-string string))
>
>           ;; In earlier versions of server.el (where we used an `emacsserver'
>           ;; process), there could be multiple lines.  Nowadays this is not
>           ;; supported any more.
>           (cl-assert (eq (match-end 0) (length string)))
> =====
>
> I get that assertion error if I do "emacsclient -c&". But if I do just "emacsclient -c", a new Emacsclient frame launches fine.

Re: emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Thanks, I reproduced the problem and installed the following patches. 
The first should fix the bug. The second should fix some display 
glitches I noticed while fixing the bug, where emacsclient wrote to the 
terminal even though it was started with a trailing '&'.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-emacsclient-hang-when-backgrounded.patch --]
[-- Type: text/x-patch; name="0001-Fix-emacsclient-hang-when-backgrounded.patch", Size: 2474 bytes --]

From 2f985977f691a37a6d45298128b88d0cefcc93a1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 6 Dec 2018 08:54:00 -0800
Subject: [PATCH 1/2] Fix emacsclient hang when backgrounded
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Kaushal Modi in:
https://lists.gnu.org/r/emacs-devel/2018-12/msg00083.html
The tcdrain call replaced an fdatasync call which had no
effect on the tty, so removing it entirely shouldn’t cause
problems.  The fdatasync call replaced an fsync call which
also had no effect on the tty, and the fsync call seems to be
badly-merged revenant of emacsclient’s old (circa 2004) way of
communicating to and from Emacs via FILE * streams, where
fsync was apparently needed when talking to sockets.
* lib-src/emacsclient.c [!DOS_NT]: Don’t include termios.h.
(flush_stdout): Remove.  All callers removed.
(main): Do not drain the tty after "Waiting for Emacs..."
message.  There should be no need to drain, and draining it
might send us a SIGTTOU.  Do not fflush stdout just before
exiting, as exiting does that for us.
---
 lib-src/emacsclient.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 7de3665114..653ab955df 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -66,10 +66,6 @@ char *w32_getenv (const char *);
 
 #endif /* !WINDOWSNT */
 
-#ifndef DOS_NT
-# include <termios.h>
-#endif
-
 #include <ctype.h>
 #include <errno.h>
 #include <getopt.h>
@@ -1740,15 +1736,6 @@ start_daemon_and_retry_set_socket (void)
   return emacs_socket;
 }
 
-/* Flush standard output and its underlying file descriptor.  */
-static void
-flush_stdout (HSOCKET emacs_socket)
-{
-  fflush (stdout);
-  while (tcdrain (STDOUT_FILENO) != 0 && errno == EINTR)
-    act_on_signals (emacs_socket);
-}
-
 int
 main (int argc, char **argv)
 {
@@ -1964,7 +1951,7 @@ main (int argc, char **argv)
       printf ("Waiting for Emacs...");
       skiplf = false;
     }
-  flush_stdout (emacs_socket);
+  fflush (stdout);
 
   /* Now, wait for an answer and print any messages.  */
   while (exit_status == EXIT_SUCCESS)
@@ -2067,7 +2054,6 @@ main (int argc, char **argv)
 
   if (!skiplf)
     printf ("\n");
-  flush_stdout (emacs_socket);
 
   if (rl < 0)
     exit_status = EXIT_FAILURE;
-- 
2.19.2


[-- Attachment #3: 0002-emacsclient-avoid-background-chatter.patch --]
[-- Type: text/x-patch, Size: 3111 bytes --]

From 46b810081165fecae5086b71fafdb3eb19c30df5 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 6 Dec 2018 10:46:06 -0800
Subject: [PATCH 2/2] emacsclient: avoid background chatter

* lib-src/emacsclient.c (process_grouping): New function.
(act_on_signals, main): Use it.
(main): Omit "Waiting for Emacs..." and later "\n" messages
if in background, since that messes up the screen.
---
 lib-src/emacsclient.c | 51 ++++++++++++++++++++++++++++---------------
 1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 653ab955df..c596fb23ae 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1095,6 +1095,26 @@ find_tty (const char **tty_type, const char **tty_name, bool noabort)
   return true;
 }
 
+/* Return the process group if in the foreground, the negative of the
+   process group if in the background, and zero if there is no
+   foreground process group for the controlling terminal.
+   Unfortunately, use of this function introduces an unavoidable race,
+   since whether the process is in the foreground or background can
+   change at any time.  */
+
+static pid_t
+process_grouping (void)
+{
+#ifdef SOCKETS_IN_FILE_SYSTEM
+  pid_t tcpgrp = tcgetpgrp (STDOUT_FILENO);
+  if (0 <= tcpgrp)
+    {
+      pid_t pgrp = getpgrp ();
+      return tcpgrp == pgrp ? pgrp : -pgrp;
+    }
+#endif
+  return 0;
+}
 
 #ifdef SOCKETS_IN_FILE_SYSTEM
 
@@ -1253,21 +1273,17 @@ act_on_signals (HSOCKET emacs_socket)
 	    {
 	      got_sigcont = 0;
 	      took_action = true;
-	      pid_t tcpgrp = tcgetpgrp (STDOUT_FILENO);
-	      if (0 <= tcpgrp)
+	      pid_t grouping = process_grouping ();
+	      if (grouping < 0)
 		{
-		  pid_t pgrp = getpgrp ();
-		  if (tcpgrp == pgrp)
-		    {
-		      /* We are in the foreground.  */
-		      send_to_emacs (emacs_socket, "-resume \n");
-		    }
-		  else if (tty)
+		  if (tty)
 		    {
-		      /* We are in the background; cancel the continue.  */
-		      kill (-pgrp, SIGTTIN);
+		      /* Cancel the continue.  */
+		      kill (grouping, SIGTTIN);
 		    }
 		}
+	      else
+		send_to_emacs (emacs_socket, "-resume \n");
 	    }
 
 	  if (got_sigtstp)
@@ -1767,13 +1783,12 @@ main (int argc, char **argv)
       exit (EXIT_FAILURE);
     }
 
-#ifndef WINDOWSNT
+#ifdef SOCKETS_IN_FILE_SYSTEM
   if (tty)
     {
-      pid_t pgrp = getpgrp ();
-      pid_t tcpgrp = tcgetpgrp (STDOUT_FILENO);
-      if (0 <= tcpgrp && tcpgrp != pgrp)
-	kill (-pgrp, SIGTTIN);
+      pid_t grouping = process_grouping ();
+      if (grouping < 0)
+	kill (grouping, SIGTTIN);
     }
 #endif
 
@@ -1946,7 +1961,7 @@ main (int argc, char **argv)
   send_to_emacs (emacs_socket, "\n");
 
   /* Wait for an answer. */
-  if (!eval && !tty && !nowait && !quiet)
+  if (!eval && !tty && !nowait && !quiet && 0 <= process_grouping ())
     {
       printf ("Waiting for Emacs...");
       skiplf = false;
@@ -2052,7 +2067,7 @@ main (int argc, char **argv)
 	}
     }
 
-  if (!skiplf)
+  if (!skiplf && 0 <= process_grouping ())
     printf ("\n");
 
   if (rl < 0)
-- 
2.19.2

Re: emacsclient not working on RHEL 6.8 (non-sudo) [master branch]

[Kaushal Modi]

On Thu, Dec 6, 2018 at 1:52 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> Thanks, I reproduced the problem and installed the following patches.
> The first should fix the bug. The second should fix some display
> glitches I noticed while fixing the bug, where emacsclient wrote to the
> terminal even though it was started with a trailing '&'.

Hi Paul,

Many thanks for fixing this issue! This breakage made emacs completely
unusable using my emacsclient .. & flow. But now I confirm things to
be working once again after building using the b1d7f19 commit.

Just for reference, I am using this bash script as a wrapper to launch
emacsclient: https://ptpb.pw/QGes/bash

Being C-illiterate, I am astounded how my bug report verbiage result
in the fix in https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2f985977f691a37a6d45298128b88d0cefcc93a1.

I don't understand the fix or the commit message at all. But thanks
again for resolving one of my RHEL 6.x specific issues once again!