GNU bug report logs - #78920
30.1; Process sentinel is not called when DNS lookup fails

Previous Next

Package: emacs;

Reported by: Shawn Henson <shawn <at> shenso.name>

Date: Sat, 28 Jun 2025 23:27:04 UTC

Severity: normal

Found in version 30.1

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: shawn <at> shenso.name, 78920 <at> debbugs.gnu.org
Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails
Date: Mon, 30 Jun 2025 15:52:45 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78920 <at> debbugs.gnu.org
> Date: Mon, 30 Jun 2025 10:01:50 +0200
> 
> >>>>> On Sun, 29 Jun 2025 17:22:36 -0400, Shawn Henson <shawn <at> shenso.name> said:
> 
>     >> I wonder what Emacs does for ":nowait t" without async DNS, when the
>     >> connect fails. I始d expect it to call the sentinel with a "failed"
>     >> status.
> 
>     Shawn> Is there a trivial way to test this?
> 
> Not without recompiling Emacs, but I始ve just tested it. It results in
> an immediate error return from `make-network-process', no process is
> created, and the sentinel is not called. That始s all as expected (now
> that I始ve had my coffee 馃榾).

Right.

> Eli, what can we do here? Whether or not Emacs is using getaddrinfo_a
> should not affect the behaviour here, although having a process be
> created is unavoidable, since we始re deferring the DNS lookup.

If we want the same behavior, we should signal an error when DNS look
up fails.

> The docstring for `make-network-process' says this in the :nowait
> section:
> 
>     the sentinel function will be called with second arg matching
>     "open" (if successful) or "failed" when the connect completes.
> 
> Pedantically, the `connect' syscall is not completed, since we never
> attempt it because of the DNS failure. But the "attempt to connect to
> the remote host" has completed, unsuccessfully, so we should call the
> sentinel (and not call it when the process is deleted).

But then the behavior will not be like we get when getaddrinfo_a is
unavailable, no?

Technically, we have no process object in this case; the fact that we
create one is an implementation detail.  I'd even go as far as saying
that this "process" should not be exposed to Lisp.
This bug report was last modified 5 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.