From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13697: Reopening Date: Thu, 04 Apr 2019 15:59:27 +0300 Message-ID: <83r2aic4eo.fsf@gnu.org> References: Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="104241"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 13697@debbugs.gnu.org To: Trey Ethan Harris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 04 15:00:20 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 1hC1ye-000R0I-5G for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Apr 2019 15:00:20 +0200 Original-Received: from localhost ([127.0.0.1]:54110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC1yd-0000KM-6p for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Apr 2019 09:00:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC1yS-0000Hf-OU for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:00:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hC1yN-0002fl-Mp for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:00:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58468) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hC1yN-0002eo-9U for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hC1yN-0007LQ-2Y for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:00:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Apr 2019 13:00:03 +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.155438279428183 (code B ref 13697); Thu, 04 Apr 2019 13:00:03 +0000 Original-Received: (at 13697) by debbugs.gnu.org; 4 Apr 2019 12:59:54 +0000 Original-Received: from localhost ([127.0.0.1]:43779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC1yD-0007KV-Jl for submit@debbugs.gnu.org; Thu, 04 Apr 2019 08:59:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC1yB-0007KJ-E2 for 13697@debbugs.gnu.org; Thu, 04 Apr 2019 08:59:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC1y5-0002Bb-Q8; Thu, 04 Apr 2019 08:59:45 -0400 Original-Received: from [176.228.60.248] (port=1374 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hC1y3-0006dU-F8; Thu, 04 Apr 2019 08:59:45 -0400 In-reply-to: (message from Trey Ethan Harris on Wed, 3 Apr 2019 17:01:38 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:157161 Archived-At: > From: Trey Ethan Harris > Date: Wed, 3 Apr 2019 17:01:38 -0400 > > 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. The problem in desktop.el was fixed in Emacs 26.1, and it didn't require any complications with threads. What other problems like that are there? Please report each such problem as a separate bug, and please let the Emacs developers decide whether they need a single unified solution, like the one proposed in this bug report, or different solutions. And in any case, just detecting that Emacs cannot interact does not yet tell what to do in each such case (and I'm not sure a single solution will fit all).