From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails Date: Sun, 11 Feb 2024 09:24:36 +0200 Message-ID: <86zfw7sbt7.fsf@gnu.org> References: <86y1c82hfb.fsf@gnu.org> <86wmrs2h41.fsf@gnu.org> <86v87c2fw4.fsf@gnu.org> <86sf2g2btj.fsf@gnu.org> <86r0hz2fcz.fsf@gnu.org> <875xywp08p.fsf@catern.com> <868r3st789.fsf@gnu.org> <8734tzq4y6.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30251"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68799@debbugs.gnu.org, sbaugh@janestreet.com To: sbaugh@catern.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 11 08:26:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rZ4E1-0007fU-2Y for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Feb 2024 08:26:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZ4Dl-0000Bh-8n; Sun, 11 Feb 2024 02:25:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZ4Di-0000BN-IL for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 02:25:47 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZ4Di-00029z-AI for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 02:25:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rZ4Dx-0002Ca-TZ for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 02:26:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Feb 2024 07:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68799 X-GNU-PR-Package: emacs Original-Received: via spool by 68799-submit@debbugs.gnu.org id=B68799.17076363028336 (code B ref 68799); Sun, 11 Feb 2024 07:26:01 +0000 Original-Received: (at 68799) by debbugs.gnu.org; 11 Feb 2024 07:25:02 +0000 Original-Received: from localhost ([127.0.0.1]:55217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZ4Cz-0002AN-Uf for submit@debbugs.gnu.org; Sun, 11 Feb 2024 02:25:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZ4Cx-00029g-Ml for 68799@debbugs.gnu.org; Sun, 11 Feb 2024 02:25:00 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZ4Cb-0001kY-SC; Sun, 11 Feb 2024 02:24:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dLPwydTOzregVWzI86ugSnJuTTFaYsYPOrJZxnH+YRk=; b=j1gkPtTo+56T UTfZH4kWVC+AJO0NCd94NvXRG0+kshg7PCfBLBEnrhc6k38wM7ifsG0H2Les5q4/9ha7XCJ7a95ZW EZgbqszp2NEtIQB5hwUTkuiqHXT48XHc3I1nqHQQcXuMR0x77CptvsLQST6Vf12G5ndY/Y0xpvACQ eKYQIZQpWQzb5zqX6ejsJNMZE6IeHsInQmW4nNxS4d10bsdMhYs1DRDopr4BI+9IUAQdfOgSCb+RZ zSiPpYSLk2W3sIwXwEvMdY4YIcwuLk0f0/Prfgkkmoay58G0LmeBsyySrlLqrUi2gZFpINPdIomi9 Kef1MnU+yESSMCp3kZJZRA==; In-Reply-To: <8734tzq4y6.fsf@catern.com> (sbaugh@catern.com) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279821 Archived-At: > From: sbaugh@catern.com > Date: Sat, 10 Feb 2024 23:23:19 +0000 (UTC) > Cc: 68799@debbugs.gnu.org, sbaugh@janestreet.com > > > What exactly is meant by "anywhere in command-line"? the function > > command-line in startup.el? or something else? > > The function command-line in startup.el. > > Or, more specifically: anywhere during the evaluation of the form in the > variable top-level, which by default is (normal-top-level). (which > calls (command-line)) Some of that code already detects errors and takes appropriate actions. I'm okay with augmenting the existing error-detecting code in startup.el with daemon-specific actions, if what we do now is not TRT for the daemon invocations. I'm also okay with identifying more places where error detection and recovery is needed, perhaps only in the daemon case. But that must be on a case by case basis, based on clear understanding what could be the reasons and the effects of those reasons. I'm not interested in "catch-all" dumb processing of startup errors without understanding them, because the recovery code will then not necessarily be correct and on target. > The reason to have a catch-all is what I just said: if there's an error > in this code, either caused by the user or from a bug in the code, it > causes Emacs to silently hang without logging an error, providing > absolutely no way for the user to know what's going wrong. Not true, at least not in all cases. Once again, the only way to make progress here that I agree to is one case at a time, based on understanding the possible reasons and on what we want Emacs (daemon or not) do in each case. > You might as well ask why we have a condition-case wrapped around > command_loop_1 which calls cmd_error, instead of just discarding the > error and continuing. The reason for doing it with command_loop_1 is well known, and is not really relevant to this discussion. > >> I have concrete reasons to want this: I think there's a bug in > >> command-line in trunk which some of my users using emacs --daemon have > >> run into. But I have zero information about what caused the bug, > >> because Emacs just hangs without printing any error message in this > >> case. > > > > Then please debug that, and let's talk when you do have concrete data. > > I can't debug that because I can't reproduce it and the failure case > leaves no information behind. That's part of the point of why we should > log on error. It's okay for you to add code locally to the relevant parts that would log the necessary information, so you can understand what happens. Please get back after you understand what went wrong, and we can then discuss whether such situations could happen with others, and whether and how to handle them. > Your argument here justifies silencing all errors in Emacs and never > writing them to *Messages*. That's obviously absurd... Yes, so let's not go "ad absurdum".