all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 68799@debbugs.gnu.org, monnier@iro.umontreal.ca, jasonr@gnu.org
Subject: bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails
Date: Tue, 13 Feb 2024 14:35:35 +0200	[thread overview]
Message-ID: <865xysr17s.fsf@gnu.org> (raw)
In-Reply-To: <ierv86tbag5.fsf@janestreet.com> (message from Spencer Baugh on Mon, 12 Feb 2024 17:10:34 -0500)

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Jason Rumney <jasonr@gnu.org>
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Mon, 12 Feb 2024 17:10:34 -0500
> 
> Spencer Baugh <sbaugh@janestreet.com> writes:
> > 1. emacs -Q --fg-daemon=/nonexistent/dir/sock
> > 2. Emacs prints "Starting Emacs daemon." and sits in foreground.
> > 3. emacsclient -c -s /nonexistent/dir/sock
> > 4. emacsclient prints and exits:
> > emacsclient: can't find socket; have you started the server?
> > emacsclient: To start the server in Emacs, type "M-x server-start".
> > emacsclient: error accessing socket "/nonexistent/dir/sock"
> >
> > This is because in step 1, the server actually failed to start, but
> > Emacs did not log that at all.  In fact, it's impossible to access the
> > Emacs started in 1 now, since it's not actually running a server and it
> > has no frames.
> 
> Okay, I found what one might call the root cause, the following code and
> comment.  Adding Stefan and Jason to CC as the original authors.
> 
> /* The initial frame is a special non-displaying frame. It
>    will be current in daemon mode when there are no frames
>    to display, and in non-daemon mode before the real frame
>    has finished initializing.  If an error is thrown in the
>    latter case while creating the frame, then the frame
>    will never be displayed, so the safest thing to do is
>    write to stderr and quit.  In daemon mode, there are
>    many other potential errors that do not prevent frames
>    from being created, so continuing as normal is better in
>    that case.  */
> || (!IS_DAEMON && FRAME_INITIAL_P (sf))
> 
> The comment is mostly sensible: we should exit while initializing, and
> shouldn't exit while in the steady state of daemon mode.

Bug#1310 and bug#1836 are also relevant here.

> However, it doesn't handle the case when Emacs is initializing *and* in
> daemon mode.  In that case, an error will prevent frames from being
> created, just like in non-daemon mode.
> 
> So this check really wants to be something more like:
> || ( IS_DAEMON && [something to check if Emacs is starting up])
> || (!IS_DAEMON && FRAME_INITIAL_P (sf))
> 
> Not sure what [something to check if Emacs is starting up] should be
> though.

after-init-time, I guess.  But note that this still leaves a window
between where that is set non-nil and starting the server.

Also, the patch for server-start which prevents it from erroring out
is still needed, because we do want to show the error message about
being unable to start the daemon.

And this solution will still print error messages that are not
specific enough to be helpful.  E.g., what do you do if you try
starting the daemon and see

   wrong-type-argument, stringp, nil

and that's all?  And that is even before we consider the use case
where stderr of the daemon is redirected to the great void, which
happens in some cases.

So my vote is still for diagnosing the important places where a fatal
error could happen, and adding a clear diagnostic there.  Yes, it is
more work.  But the gain will be much higher.





  reply	other threads:[~2024-02-13 12:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 16:54 bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails Spencer Baugh
2024-01-29 17:11 ` Eli Zaretskii
2024-01-29 17:18   ` Eli Zaretskii
2024-01-29 17:32     ` Spencer Baugh
2024-01-29 17:44       ` Eli Zaretskii
2024-01-29 18:13         ` Spencer Baugh
2024-01-29 19:12           ` Eli Zaretskii
2024-01-29 20:28             ` Spencer Baugh
2024-01-30 12:08               ` Eli Zaretskii
2024-02-10 19:50                 ` sbaugh
2024-02-10 20:05                   ` Eli Zaretskii
2024-02-10 23:23                     ` sbaugh
2024-02-11  7:24                       ` Eli Zaretskii
2024-02-12 22:10 ` Spencer Baugh
2024-02-13 12:35   ` Eli Zaretskii [this message]
2024-02-13 17:37     ` Spencer Baugh
2024-02-13 17:49       ` Eli Zaretskii
2024-02-13 18:04         ` Spencer Baugh
2024-02-13 19:46           ` Eli Zaretskii
2024-02-13 20:02             ` Spencer Baugh
2024-02-13 20:04               ` Eli Zaretskii
2024-02-13 20:20                 ` Spencer Baugh
2024-02-14 14:23                   ` Eli Zaretskii
2024-02-14 16:11                     ` Spencer Baugh
2024-02-24  9:20                       ` Eli Zaretskii
2024-02-13 13:02   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-13 21:30 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found] ` <875xys127y.fsf@>
2024-02-14 14:35   ` Eli Zaretskii
2024-02-14 15:10     ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]     ` <87plwzytcg.fsf@>
2024-02-14 15:31       ` Eli Zaretskii
2024-02-14 17:40         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=865xysr17s.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=68799@debbugs.gnu.org \
    --cc=jasonr@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.