From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Trey Ethan Harris Newsgroups: gmane.emacs.bugs Subject: bug#13697: Reopening Date: Wed, 3 Apr 2019 17:01:38 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000eea6990585a68fbc" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35080"; mail-complaints-to="usenet@blaine.gmane.org" To: 13697@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 23:33:34 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBnVi-0008rn-1E for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 23:33:30 +0200 Original-Received: from localhost ([127.0.0.1]:55894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBnVg-0002Js-Fb for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 17:33:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBnVN-0002Iw-W7 for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 17:33:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBnVL-0005R7-US for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 17:33:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58035) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBnVG-0005Ky-Ih for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 17:33:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hBnVG-0001zs-B4 for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 17:33:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Trey Ethan Harris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2019 21:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13697 X-GNU-PR-Package: emacs Original-Received: via spool by 13697-submit@debbugs.gnu.org id=B13697.15543271287577 (code B ref 13697); Wed, 03 Apr 2019 21:33:02 +0000 Original-Received: (at 13697) by debbugs.gnu.org; 3 Apr 2019 21:32:08 +0000 Original-Received: from localhost ([127.0.0.1]:43340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBnUN-0001y9-Ma for submit@debbugs.gnu.org; Wed, 03 Apr 2019 17:32:08 -0400 Original-Received: from mail-io1-f45.google.com ([209.85.166.45]:39613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBn19-0001DM-MY for 13697@debbugs.gnu.org; Wed, 03 Apr 2019 17:01:56 -0400 Original-Received: by mail-io1-f45.google.com with SMTP id e13so117586ioq.6 for <13697@debbugs.gnu.org>; Wed, 03 Apr 2019 14:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=muu5SzDZ2ZzuYJXhYiec0G0M/85zn6/b1INRaJZaYR0=; b=Cp5+IsbPkDwXWezpMHPmOK/1QJ5ay5qj/9PMLF2citcuFLk8hEbR/cBMM1KRljevhy GZ3QslhJi/9it8RvXJz+1ICuFmpD6WHSlvUeZE9e0FBj6Fj8q06t//ANm7j5r2EfYlDc WTPEmQoRnGB9iapy/5xO/YZfBCtp4lXCQN/6AJS1pj7fD5ymIXs1hjXq63zZxD9UTPdJ F4vg8ETCKRhqIyWZRpX7SHBKladObBbfVvHIWHNaGT4w713bg/EjzzekZnq2La4gNex4 rgCwnSUpkLesS2hPGuqHYc3vTdQ/R47ZWcovrgSz3U1YiQiARGZGdK48UmtDQR+K/K4M GsmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=muu5SzDZ2ZzuYJXhYiec0G0M/85zn6/b1INRaJZaYR0=; b=Gb26OCV3/0zMZdIVMPIJtN86hXapiQhxHWHF/IfqM4tvI/fq0VdSfEOwWlqhhtseGd wcZOiKIDT1vgHJyBHzVYdegsTFtvN/xzV5jEAhRFotBqeSvPBJAZ03DPYCPCbFZr5/Kk hXi3nGStvhnMHOJ25n3eYup6UNXoAJZA+byo038yRXvmI4Tlqucx4nO0pwid7DHPDWpK 3GQmBL/fOV+rSqI7C7rSdsvwUthjxh61+VsRsnmgQrDbfxy3iQ2pbItJlFdVGliqxMvA g73dJnLtd9cwB7tCcu3JknX5BCM/Vl0zvPDX19q15LKDbZnNyKmdiCXaEpH5teUMX8kW h7pQ== X-Gm-Message-State: APjAAAXzJ1rJYkRCDlopbOKJi2N5wcAi4ARBpBKc6+CtRt2BRWgUhLMi ryDUJY7lS6STdocQgvwb2K2CqIWR7GFyF9SFEs9fjeMpeKY= X-Google-Smtp-Source: APXvYqyxMVWyGsQE7wwXSAZtSrmFAyp8VjeL3O1AERN3Q3eYWUIfejRn4PcF/tG6l5k0v1SyUpRWtp47wmNJHpAKfT0= X-Received: by 2002:a5d:9159:: with SMTP id y25mr1793083ioq.146.1554325309399; Wed, 03 Apr 2019 14:01:49 -0700 (PDT) X-Mailman-Approved-At: Wed, 03 Apr 2019 17:32:06 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157138 Archived-At: --000000000000eea6990585a68fbc Content-Type: text/plain; charset="UTF-8" As described in the Emacs Stack Exchange question, https://emacs.stackexchange.com/questions/32692/daemon-mode-defer-interactive-prompts-on-startup/ , this bug seems to be applicable and should be reopened. Many people seem to be attempting to run `emacs --daemon` as part of their system on login startup--mostly as a way to improve emacsclient initialization time when Emacs is first needed--but they run into trouble because systemd or other startup system or the GUI login process is non-interactive. If Emacs attempts to interact in any way at startup time, then the daemon startup hangs. There is no way AFAIK to respond to such an interaction--the Emacs server hasn't started yet, so emacsclient can't be used. The issue can exacerbate system issues, especially after abnormal exit. If the user uses the empty-string form of ALTERATE_EDITOR, they may unwittingly start up multiple Emacs daemons that will all hang at the same point in startup. If they so configure their startup system with a watchdog functionality, they may repeatedly kill and restart the Emacs daemon, doing nothing but drawing useless CPU and IO. One can workaround the issue in a piecemeal fashion by overriding or advising functions in startup packages that may interact (for instance, advising `desktop-restore-file-buffer` so that it will not block if the daemon is being restarted from a crash and a desktop lockfile still exists). However, this is not a general solution--one can never know for certain from where an interaction might arise. Of course Emacs itself can't supply a 100% solution--the user could always put something in initialization which blocks on interaction, even if it's specific Elisp to do so or a call out to a shell program. But Emacs _could,_ I think, provide a 99% solution: 1. Intercept interaction functions like `yes-or-no-p` and password prompts running in asynchronous threads, allowing them to block their thread 2. Automatically convert interaction in other threads into a warning failure 3. Continue execution of other threads so that the server can start 4. Upon first connection with an emacsclient, display the warnings (presumably by popping up *Warnings*) so that the user is aware of what may have failed in initialization due to inability to interact 5. Take the user through the queued blocked threads so they can complete the threaded interactions. I have tried to do this in a pure user-side Elisp way, but I don't think it's possible without Emacs' assistance. --000000000000eea6990585a68fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As described in the Emacs Stack Exchange ques= tion,=C2=A0https://emacs.stackexchange.c= om/questions/32692/daemon-mode-defer-interactive-prompts-on-startup/ , = this bug seems to be applicable and should be reopened.

Many people = seem to be attempting to run `emacs --daemon` as part of their system on lo= gin startup--mostly as a way to improve emacsclient initialization time whe= n Emacs is first needed--but they run into trouble because systemd or other= startup system or the GUI login process is non-interactive. If Emacs attem= pts to interact in any way at startup time, then the daemon startup hangs.<= /div>

There is no way AFAIK to respond to such an interaction--the Emacs s= erver hasn't started yet, so emacsclient can't be used.

=
The = issue can exacerbate system issues, especially after abnormal exit. If the = user uses the empty-string form of ALTERATE_EDITOR, they may unwittingly st= art up multiple Emacs daemons that will all hang at the same point in start= up. If they so configure their startup system with a watchdog functionality= , they may repeatedly kill and restart the Emacs daemon, doing nothing but = drawing useless CPU and IO.

One can workaround the issue in a piec= emeal fashion by overriding or advising functions in startup packages that = may interact (for instance, advising `desktop-restore-file-buffer` so that = it will not block if the daemon is being restarted from a crash and a deskt= op lockfile still exists). However, this is not a general solution--one can= never know for certain from where an interaction might arise.

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">Of co= urse Emacs itself can't supply a 100% solution--the user could always p= ut something in initialization which blocks on interaction, even if it'= s specific Elisp to do so or a call out to a shell program.

But Emac= s _could,_ I think, provide a 99% solution:

1. Intercept interaction= functions like `yes-or-no-p` and password prompts running in asynchronous = threads, allowing them to block their thread
2. Automatically convert inte= raction in other threads into a warning failure
3. Continue execution of o= ther threads so that the server can start
4. Upon first connection with an= emacsclient, display the warnings (presumably by popping up *Warnings*) so= that the user is aware of what may have failed in initialization due to in= ability to interact
5. Take the user through the queued blocked threads so= they can complete the threaded interactions.

I have tried to do thi= s in a pure user-side Elisp way, but I don't think it's possible wi= thout Emacs' assistance.
--000000000000eea6990585a68fbc--