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


Message #17 received at 78920 <at> debbugs.gnu.org (full text, mbox):

From: Shawn Henson <shawn <at> shenso.name>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: 78920 <at> debbugs.gnu.org
Subject: Re: bug#78920: 30.1; Process sentinel is not called when DNS lookup
 fails
Date: Sun, 29 Jun 2025 05:17:18 -0400
On 6/29/25 4:18 AM, Eli Zaretskii wrote:
>> Date: Sun, 29 Jun 2025 03:59:17 -0400
>> Cc: 78920 <at> debbugs.gnu.org
>> From: Shawn Henson <shawn <at> shenso.name>
>>
>>
>> On 6/29/25 1:13 AM, Eli Zaretskii wrote:
>>>> Date: Sat, 28 Jun 2025 18:04:07 -0400
>>>> From: Shawn Henson <shawn <at> shenso.name>
>>>>
>>>> I was testing a function of mine which wraps `url-retrieve', and I found
>>>> myself confused that my callback was not being reached with bad
>>>> host names, and upon debugging discovered the process sentinel was not
>>>> being called at all. Using the Lisp debugger added further confusion
>>>> because the process status of the returned buffer would be "failed", but
>>>> this was not the case during normal evaluation due to race conditions.
>>>>
>>>> You can reproduce this with make-network-process:
>>>>
>>>> ```
>>>> (let ((my-test-proc (make-network-process :name "dns-fail-test"
>>>>                                              :buffer "dns-fail-test-buf"
>>>>                                              :host "thisisnotarealhostname"
>>>>                                              :service 80
>>>>                                              :nowait t
>>>>                                              :sentinel (lambda (process event)
>>>>                                                          (print event)))))
>>>>      (message "process status: %s" (process-status my-test-proc)))
>>>> ```
>>>>
>>>> After evaluation, the *Messages* buffer includes:
>>>>
>>>> ```
>>>> process status: connect
>>>> ```
>>> What happens if you use ':nowait nil' instead?  Is the sentinel get
>>> called?
>> In this case, an error is signaled upon evaluating the function:
>>
>> ```
>> Debugger entered--Lisp error: (error "thisisnotarealhostname/80 Name or
>> service not known")
>>     make-network-process(:name "dns-fail-test" :buffer
>> "dns-fail-test-buf" :host "thisisnotarealhostname" :service 80 :nowait
>> nil :sentinel #f(lambda (process event) [t] (print event)))
>> ```
>>
>> This seems in line with the function documentation, which seems to
>> confirm the sentinel should be
>> called when it is 't', which is the case for `url-retrieve'.
>>
>> ```
>> :nowait BOOL -- If NOWAIT is non-nil for a stream type client
>> process, return without waiting for the connection to complete;
>> instead, the sentinel function will be called with second arg matching
>> "open" (if successful) or "failed" when the connect completes.
>> Default is to use a blocking connect (i.e. wait) for stream type
>> connections.
>> ```
> Yes, but when the problem is with the DNS resolution, there's no 
> connection, and technically no running process. The "failed" status is 
> never reached because of that. Robert, WDYT? 
I see, though, interestingly if you are to run the `list-processes' you 
will see it persist there
indefinitely with a "failed" status.  And if you do kill it, then the 
process sentinel will be
called.

```
Process   PID      Status  Buffer         TTY Thread         Command
dns-fail-test   --      failed  dns-fail-test-buf --           
Main         (network connection to nil:nil)
```





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.