bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails

[sbaugh@catern.com]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 68799@debbugs.gnu.org
>> Date: Mon, 29 Jan 2024 15:28:47 -0500
>> 
>> >> --- a/lisp/startup.el
>> >> +++ b/lisp/startup.el
>> >> @@ -1627,7 +1627,11 @@ command-line
>> >>    (let ((dn (daemonp)))
>> >>      (when dn
>> >>        (when (stringp dn) (setq server-name dn))
>> >> -      (server-start)
>> >> +      (condition-case err
>> >> +          (server-start)
>> >> +        (error
>> >> +         (message "%s" (error-message-string err))
>> >> +         (kill-emacs 1)))
>> >
>> > Thanks, this needs a comment explaining why we need condition-case and
>> > where does error-message-string come from.
>> 
>> Actually, on second thought, we could fail anywhere in startup.el, not
>> just in server-start.  So should we actually have a wrapper around all
>> of normal-top-level which detects an error at startup in a daemon?
>
> I'd prefer to handle each specific problem specially, to make sure the
> error message is self-explanatory.  Also, if the error happens after
> the server has been started, there's no reason to forcibly exit.
>
> So I think we should for now solve this particular issue, and not try
> generalizing too much.

To be clear, right now any error anywhere in command-line causes "emacs
--fg-daemon" and "emacs --bg-daemon" to hang indefinitely, without
printing an error, with no way to ever interact with the Emacs process.
This error can come from any code, so if we have *any* bugs anywhere in
code called from command-line, it will cause Emacs to enter this state.

We can add good error messages for individual classes of error, but we
should also have a catch-all check to make sure that Emacs doesn't enter
this broken state if we (or the user) write code which contains a bug.

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.

To allow users to report bugs that are at all useful, we should at least
print the error that occurred, even if we don't kill Emacs.