From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Shawn Henson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 23:27:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78920@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17511532089377 (code B ref -1); Sat, 28 Jun 2025 23:27:04 +0000 Received: (at submit) by debbugs.gnu.org; 28 Jun 2025 23:26:48 +0000 Received: from localhost ([127.0.0.1]:52730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVewV-0002QU-V5 for submit@debbugs.gnu.org; Sat, 28 Jun 2025 19:26:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57942) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVdeu-0006OW-5X for submit@debbugs.gnu.org; Sat, 28 Jun 2025 18:04:30 -0400 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 1uVdeo-0006WB-HJ for bug-gnu-emacs@gnu.org; Sat, 28 Jun 2025 18:04:22 -0400 Received: from sender4-op-o15.zoho.com ([136.143.188.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uVdel-0008UQ-9K for bug-gnu-emacs@gnu.org; Sat, 28 Jun 2025 18:04:22 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1751148253; cv=none; d=zohomail.com; s=zohoarc; b=mKc5vuiV7ILNY+qUrFt8TrsyNySR2QuiyheUAPfaR7vEhINgr+VEob/BojXXlpYH5cqxxtDCEAwkYhGhMylAQsMwrUsq3ff/FHACCjYDB5AsIKF6TInSs1qnfN6MlkOhJD+ZLsR76+eGuULlfz3X+r5/ofui7+GwVoXjOc0LCng= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1751148253; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=Gdyz08p2zsOKxlrDyBQIjavzdkZmNWxLasp95RWRHdU=; b=P8bMzWRvojI9dEMqL0m6ZRLu90RR7EBO7EYoUDpczhmit/pDiU6+R1dHgmKVXwGmwZnwQO6Bi+OyBet72ZRsEI2LCwh89vLOKKuMH7v3a/jVucYt5yKKdVNMtMtO8YzEwN4+CC9gE9W6GJFWBqmf1ibxWHQoedtNmOjHk8iBIiU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=shenso.name; spf=pass smtp.mailfrom=shawn@shenso.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1751148253; s=shenso; d=shenso.name; i=shawn@shenso.name; h=Message-ID:Date:Date:MIME-Version:From:From:Subject:Subject:To:To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=Gdyz08p2zsOKxlrDyBQIjavzdkZmNWxLasp95RWRHdU=; b=gAMoKUUo5tn2uZFUSi3gLYAvXWQX/k7acj81Ry7DE7kHRHVEfhnaBXiivkso2lIR i/mNLMsjiNzyI6K1jP3ELH96GeKHdqEQDATAl/Uq9CipEKBb5YX+Rrz+Zw1RQwIxqmO 4IhmSocT3Lnf0lepFU56s8vZBcVzRB7eCrKe0iGg= Received: by mx.zohomail.com with SMTPS id 175114825005912.225922922492941; Sat, 28 Jun 2025 15:04:10 -0700 (PDT) Message-ID: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> Date: Sat, 28 Jun 2025 18:04:07 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Shawn Henson Content-Language: en-US Autocrypt: addr=shawn@shenso.name; keydata= xjMEaCEU5BYJKwYBBAHaRw8BAQdAjWuXCEe7ixkzRdRWLR+Iq4krQtuKZ3qbvyWNbNKU9dnN IFNoYXduIEhlbnNvbiA8c2hhd25Ac2hlbnNvLm5hbWU+wpkEExYKAEECGwMFCQlmAYAFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AWIQSYJumcFOWOyx5hquml6jo4WVLKCwUCaCIZ+wIZAQAK CRCl6jo4WVLKCyS3AQC0/NFzV1gC0PEdcWrt3uKvLPVNtFhYRH2VML6/Z/RPsQD/QLDHWwB6 sCFDLneQkusaCzlsTOdifhkyNiS4YEpuhgfOOARoIVrEEgorBgEEAZdVAQUBAQdAvCJlLX6A 6cBN+Xfr7EYJlf65MjFKszLe8TaLR5DCnF0DAQgHwn4EGBYKACYWIQSYJumcFOWOyx5hquml 6jo4WVLKCwUCaCFaxAIbDAUJAeEzgAAKCRCl6jo4WVLKC3I/AP96wvs/HdxdbCCICY32PFWD itXMPaDmiG9Jpj5jm1QNNgD9H8Ny8OYDUWeEeA2jkR2yL48ueTM7o30VvEMr3r6lwwY= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.15; envelope-from=shawn@shenso.name; helo=sender4-op-o15.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Sat, 28 Jun 2025 19:26:42 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 ``` If you run `list-processes' you will see a failed status (if you have a decent internet connection) despite no message from the sentinel. However, if you were to take the lisp code above, and use "gnu.org" as the host, you will get the following output in the message buffer: ``` process status: connect "open " ``` Running GDB on Emacs, I could see the the status was being set to failed at process.c:5170: ```   /* The DNS lookup failed. */   else if (connecting_status (p->status))     {       deactivate_process (proc);       pset_status (p, (list2                (Qfailed,             concat3 (build_string ("Name lookup of "),                  build_string (p->dns_request->ar_name),                  build_string (" failed")))));     } ``` I presume nowhere in the call stack does the sentinel get notified of the status change. Perhaps I am wrong to assume this is unintentional, though, as far as I'm aware the only way to detect this failure is through a timer, which introduces unnecessary lag to handling. I did my best to check the bug tracker and mailing lists for this issue, but it is my first time submitting a bug so I apologize if I missed a pre-existing report in my naivety. Best, Shawn In GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo  version 1.18.4, Xaw3d scroll bars) of 2025-03-30, modified by Debian  built on sbuild Windowing system distributor 'The X.Org Foundation', version 11.0.12101016 System Description: Debian GNU/Linux 13 (trixie) Configured using:  'configure --build x86_64-linux-gnu --prefix=/usr  --sharedstatedir=/var/lib --libexecdir=/usr/libexec  --localstatedir=/var/lib --infodir=/usr/share/info  --mandir=/usr/share/man --with-libsystemd --with-pop=yes  --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp  --with-sound=alsa --without-gconf --with-mailutils --build  x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib  --libexecdir=/usr/libexec --localstatedir=/var/lib  --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd  --with-pop=yes  --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp  --with-sound=alsa --without-gconf --with-mailutils --with-x=yes  --with-x-toolkit=lucid --with-toolkit-scroll-bars --without-gsettings  'CFLAGS=-g -O2 -Werror=implicit-function-declaration  -ffile-prefix-map=/build/reproducible-path/emacs-30.1+1=. -fstack-protector-strong  -fstack-clash-protection -Wformat -Werror=format-security  -fcf-protection -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'  LDFLAGS=-Wl,-z,relro' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings:   value of $LANG: en_US.UTF-8   locale-coding-system: utf-8-unix Major mode: C/*l Minor modes in effect:   bug-reference-prog-mode: t   projectile-mode: t   windmove-mode: t   server-mode: t   display-fill-column-indicator-mode: t   display-line-numbers-mode: t   hl-line-mode: t   global-evil-collection-unimpaired-mode: t   evil-collection-unimpaired-mode: t   evil-mode: t   evil-local-mode: t   nyan-mode: t   lsp-bridge-mode: t   yas-global-mode: t   yas-minor-mode: t   ivy-mode: t   hexl-follow-ascii: t   override-global-mode: t   straight-use-package-mode: t   straight-package-neutering-mode: t   straight-live-modifications-mode: t   tooltip-mode: t   global-eldoc-mode: t   show-paren-mode: t   electric-indent-mode: t   mouse-wheel-mode: t   tool-bar-mode: t   menu-bar-mode: t   file-name-shadow-mode: t   global-font-lock-mode: t   font-lock-mode: t   blink-cursor-mode: t   minibuffer-regexp-mode: t   column-number-mode: t   line-number-mode: t   indent-tabs-mode: t   transient-mark-mode: t   auto-composition-mode: t   auto-encryption-mode: t   auto-compression-mode: t   abbrev-mode: t Load-path shadows: /home/shenso/.config/emacs/elisp/macros hides /usr/share/emacs/30.1/lisp/macros /home/shenso/.local/share/emacs/straight/build/modus-themes/theme-loaddefs hides /usr/share/emacs/30.1/lisp/theme-loaddefs /home/shenso/.local/share/emacs/straight/build/bind-key/bind-key hides /usr/share/emacs/30.1/lisp/bind-key /home/shenso/.local/share/emacs/straight/build/transient/transient hides /usr/share/emacs/30.1/lisp/transient /home/shenso/.local/share/emacs/straight/build/jsonrpc/jsonrpc hides /usr/share/emacs/30.1/lisp/jsonrpc /home/shenso/.local/share/emacs/straight/build/use-package/use-package-core hides /usr/share/emacs/30.1/lisp/use-package/use-package-core /home/shenso/.local/share/emacs/straight/build/use-package/use-package-lint hides /usr/share/emacs/30.1/lisp/use-package/use-package-lint /home/shenso/.local/share/emacs/straight/build/use-package/use-package-bind-key hides /usr/share/emacs/30.1/lisp/use-package/use-package-bind-key /home/shenso/.local/share/emacs/straight/build/use-package/use-package-delight hides /usr/share/emacs/30.1/lisp/use-package/use-package-delight /home/shenso/.local/share/emacs/straight/build/use-package/use-package-ensure-system-package hides /usr/share/emacs/30.1/lisp/use-package/use-package-ensure-system-package /home/shenso/.local/share/emacs/straight/build/use-package/use-package-ensure hides /usr/share/emacs/30.1/lisp/use-package/use-package-ensure /home/shenso/.local/share/emacs/straight/build/use-package/use-package-diminish hides /usr/share/emacs/30.1/lisp/use-package/use-package-diminish /home/shenso/.local/share/emacs/straight/build/use-package/use-package hides /usr/share/emacs/30.1/lisp/use-package/use-package /home/shenso/.local/share/emacs/straight/build/use-package/use-package-jump hides /usr/share/emacs/30.1/lisp/use-package/use-package-jump /home/shenso/.local/share/emacs/straight/build/compat/compat hides /usr/share/emacs/30.1/lisp/emacs-lisp/compat /home/shenso/.local/share/emacs/straight/build/map/map hides /usr/share/emacs/30.1/lisp/emacs-lisp/map /home/shenso/.local/share/emacs/straight/build/seq/seq hides /usr/share/emacs/30.1/lisp/emacs-lisp/seq Features: (shadow emacsbug message rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils goto-addr view add-log which-func octave vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util js c-ts-common imenu loaddefs-gen face-remap yank-media mail-extr cua-base modus-operandi-tritanopia-theme modus-themes find-lisp vc bug-reference cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sort find-dired all-the-icons-dired mule-util delsel tabify jka-compr tramp-cache time-stamp tramp-sh shortdoc ivy-overlay ielm asyncio-test-promise ert ewoc misearch multi-isearch help-fns radix-tree cl-print asyncio evil-collection-edebug edebug evil-collection-debug debug backtrace vc-git evil-collection-diff-mode diff-mode track-changes vc-dispatcher go-mode url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap find-file ffap etags fileloop projectile ibuf-ext ibuffer ibuffer-loaddefs windmove network-stream puny nsm time server checkdoc lisp-mnt flymake display-fill-column-indicator display-line-numbers hl-line cus-start evil-org-agenda evil-org org-element org-persist org-id org-refile org-element-ast inline avl-tree generator evil-dired evil-collection-ivy evil-collection-unimpaired evil-collection-info evil-collection-help evil-collection-grep evil-collection-dired evil-collection-custom evil-collection-calendar evil-collection annalist evil evil-integration evil-maps evil-commands reveal evil-jumps evil-command-window evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common rect evil-vars diminish diminish-autoloads nyan-mode nyan-mode-autoloads all-the-icons-dired-autoloads all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons all-the-icons-autoloads org-pretty-theme org-indent org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie executable ob-comint org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs org-compat org-version org-macs shenso-font-theme theme-timer modus-themes-autoloads nordic-night-theme nordic-night-theme-autoloads yaml-mode-autoloads lsp-bridge lsp-bridge-rust lsp-bridge-semantic-tokens lsp-bridge-dart lsp-bridge-inlay-hint lsp-bridge-org-babel lsp-bridge-lsp-installer lsp-bridge-diagnostic lsp-bridge-code-action acm acm-quick-access acm-backend-capf acm-backend-tabby acm-backend-jupyter acm-backend-org-roam acm-backend-copilot acm-backend-codeium array acm-backend-ctags xref acm-backend-citre acm-backend-tabnine acm-backend-telega acm-backend-tempel acm-backend-search-sdcv-words acm-backend-search-file-words acm-backend-path acm-backend-lsp-workspace-symbol acm-backend-lsp acm-backend-elisp acm-backend-yas acm-icon svg dom xml lsp-bridge-call-hierarchy lsp-bridge-peek comp comp-cstr comp-run comp-common lsp-bridge-jdtls lsp-bridge-ref derived grep lsp-bridge-epc acm-frame diff markdown-mode url-parse url-vars thingatpt noutline outline csv-mode-autoloads sql-indent-autoloads bigquery bigquery-autoloads typescript-mode-autoloads go-mode-autoloads flutter-autoloads dart-mode-autoloads yasnippet yasnippet-autoloads shenso-windowing advice projectile-autoloads ivy ivy-faces colir ivy-autoloads dired-subtree-hack dired-subtree dired-hacks-utils dired-aux dash dired-subtree-autoloads dired-hacks-utils-autoloads dash-autoloads gptel-autoloads ement-autoloads svg-lib-autoloads taxy-magit-section-autoloads taxy-autoloads plz-autoloads persist-autoloads map-autoloads dape jsonrpc pcase warnings tramp rx trampver tramp-integration files-x tramp-message tramp-compat xdg shell pcomplete parse-time iso8601 time-date format-spec auth-source eieio eieio-core password-cache tramp-loaddefs hexl gdb-mi bindat gud project compile text-property-search repeat comint ansi-osc ansi-color ring pulse color dape-autoloads jsonrpc-autoloads lsp-bridge-autoloads markdown-mode-autoloads magit-autoloads with-editor-autoloads transient-autoloads magit-section-autoloads llama-autoloads compat-autoloads seq-autoloads exec-path-from-shell json map exec-path-from-shell-autoloads vterm-autoloads free-keys free-keys-autoloads evil-org-autoloads evil-collection-autoloads annalist-autoloads edmacro kmacro byte-opt evil-autoloads goto-chg-autoloads finder-inf use-package-bind-key bind-key easy-mmode treesit use-package-ensure use-package-core use-package-autoloads info bind-key-autoloads straight-autoloads cl-extra help-mode straight subr-x cl-macs gv bytecomp byte-compile package-helper dired dired-loaddefs macros cl-seq cus-edit pp cus-load icons wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 1101798 3861611) (symbols 48 48350 2)  (strings 32 176930 140541) (string-bytes 1 6746814)  (vectors 16 80423) (vector-slots 8 1325257 675661)  (floats 8 2282 61226) (intervals 56 51724 47167) (buffers 992 61)) From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 05:14:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson Cc: 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175117399628938 (code B ref 78920); Sun, 29 Jun 2025 05:14:03 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 05:13:16 +0000 Received: from localhost ([127.0.0.1]:54010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVkLr-0007Wf-Pr for submit@debbugs.gnu.org; Sun, 29 Jun 2025 01:13:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39928) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVkLp-0007Vs-SK for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 01:13:14 -0400 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 1uVkLj-0002yh-69; Sun, 29 Jun 2025 01:13:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=u7KlNIes1BWdk+79aQKXHTAigXYaNeSzNxha/rgiNsE=; b=THooPCYfVSAjgPloNuyT vDTf2eqCy6mVEWAy/GbW3LibfW8VdmYn9cqJs6xkg0N+ocODRFeTZcrnpWARNWgAtzKp8YNPc6tCR fAEMeX4OMumse4HfbHbBsI09czO+y6tpGlvY9YIzThjTmzxDJHrlQU4/EjwfBXh2g/QJjKvDhAheW ZCom87d2hlCV4c+V00G+5TOH5XBrGl//5oRf2hWUvNqpBa1bODfmwW78VNeOQkbGVqL5vAPzffHL7 kmMPN9gF6+uobUjdM2Lx72FeLXGfZLj8csskPkNV37LagRLIPexLqfxJQjfpsBwScYpRLP91YW9y8 cey+HHqGXSDQZA==; Date: Sun, 29 Jun 2025 08:13:04 +0300 Message-Id: <86bjq75dwf.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> (message from Shawn Henson on Sat, 28 Jun 2025 18:04:07 -0400) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 28 Jun 2025 18:04:07 -0400 > From: Shawn Henson > > 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? From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Shawn Henson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 08:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175118397314313 (code B ref 78920); Sun, 29 Jun 2025 08:00:04 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 07:59:33 +0000 Received: from localhost ([127.0.0.1]:54675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVmwm-0003ih-K5 for submit@debbugs.gnu.org; Sun, 29 Jun 2025 03:59:33 -0400 Received: from sender4-op-o12.zoho.com ([136.143.188.12]:17280) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVmwj-0003iB-3F for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 03:59:30 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1751183962; cv=none; d=zohomail.com; s=zohoarc; b=JS57No5o4cEfY+GioB5SXRZUdH/djGLoAYi37+MtoL3ZwsthPMATXxx3BxxmdlVCYozf9Dg+nNPD/2HqZn0UeWpa2weJfAcdbeuY7lpcIrTT71CXT36NUO3usvlSxKZyMvEVMtSADONQcl5hqWOD6bsi0XbBJPwXin/Zci2Sb6U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1751183962; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=bwVFnsxEYr+aw+Q+42yMNanZ49NY4Mltv00otEkZ1+0=; b=krI3thm9DgrNy65uMI0K6EDhli2FptiSpfdby3HRAvp0lJXNajHy8nbVSh4o3j3DLXIXcZ3LZbT2PI1mFQWMc0nU+YrchdK73p/VLWKqz7DI8yx/Ijsb73QQNMqb6DkIp4yjMn+wJMJmyW2qogonHa1V/awtAxUcYwrNSl5of0k= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=shenso.name; spf=pass smtp.mailfrom=shawn@shenso.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1751183962; s=shenso; d=shenso.name; i=shawn@shenso.name; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=bwVFnsxEYr+aw+Q+42yMNanZ49NY4Mltv00otEkZ1+0=; b=JYPNW08Wch4kNGwhlJdavQn9Vz2H3WxUETQGfPkQPz1F5CHZTPZOODM9bS7VFDC7 FyygQ8d5X5ZQD03wsck84YhL187TuIB6OuGECvdI9PMvmVyhuB2uK3+MCrwbaNUgl0k TZIRJeX6PbZ0oj+Fg8bLkgfHHEWS7FSeQFHxJupY= Received: by mx.zohomail.com with SMTPS id 1751183960005961.1209307658744; Sun, 29 Jun 2025 00:59:20 -0700 (PDT) Message-ID: <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> Date: Sun, 29 Jun 2025 03:59:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> Content-Language: en-US From: Shawn Henson Autocrypt: addr=shawn@shenso.name; keydata= xjMEaCEU5BYJKwYBBAHaRw8BAQdAjWuXCEe7ixkzRdRWLR+Iq4krQtuKZ3qbvyWNbNKU9dnN IFNoYXduIEhlbnNvbiA8c2hhd25Ac2hlbnNvLm5hbWU+wpkEExYKAEECGwMFCQlmAYAFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AWIQSYJumcFOWOyx5hquml6jo4WVLKCwUCaCIZ+wIZAQAK CRCl6jo4WVLKCyS3AQC0/NFzV1gC0PEdcWrt3uKvLPVNtFhYRH2VML6/Z/RPsQD/QLDHWwB6 sCFDLneQkusaCzlsTOdifhkyNiS4YEpuhgfOOARoIVrEEgorBgEEAZdVAQUBAQdAvCJlLX6A 6cBN+Xfr7EYJlf65MjFKszLe8TaLR5DCnF0DAQgHwn4EGBYKACYWIQSYJumcFOWOyx5hquml 6jo4WVLKCwUCaCFaxAIbDAUJAeEzgAAKCRCl6jo4WVLKC3I/AP96wvs/HdxdbCCICY32PFWD itXMPaDmiG9Jpj5jm1QNNgD9H8Ny8OYDUWeEeA2jkR2yL48ueTM7o30VvEMr3r6lwwY= In-Reply-To: <86bjq75dwf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 6/29/25 1:13 AM, Eli Zaretskii wrote: >> Date: Sat, 28 Jun 2025 18:04:07 -0400 >> From: Shawn Henson >> >> 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. ``` From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 08:19:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson , Robert Pluim Cc: 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175118510424929 (code B ref 78920); Sun, 29 Jun 2025 08:19:03 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 08:18:24 +0000 Received: from localhost ([127.0.0.1]:54716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVnF0-0006Tt-SV for submit@debbugs.gnu.org; Sun, 29 Jun 2025 04:18:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVnEy-0006Sl-0v for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 04:18:21 -0400 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 1uVnEr-0000BU-Bs; Sun, 29 Jun 2025 04:18:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=THznH+GnS4ObTv4tUi+kR+11O6JomoqVXdeCv2H4GR0=; b=duBBDHpliJj6XpU+ExLn HxZiNnocBpt6SkAWXmp1N/d6gtRDZm3fho2EjOjkJSIHO6TnWquqb3XcTFmoC3wyrVQe2VVtk/4+8 3enh8hye0Ue3SC78egNUvgBkAhIEogm1VKtPy393J1HQB5p8V69DRjyj/spb2JHdBGIe8olYRHIx+ 8OllSmFkK9gs9lDudRAxEm1xZVJ52DYMz8T3vIWQ5yytnu9r7Xp9zz+2k++vydAQqkGSDt5nTzVaB anIUKHnGkCMC5999L3QMt4QK3QpupogZQWWNudNeIPxJ6Oh31kbgOAjdmnMIzXpfh1txcXNqPTaTy dait4mFZv3XDpA==; Date: Sun, 29 Jun 2025 11:18:10 +0300 Message-Id: <8634bj55bx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> (message from Shawn Henson on Sun, 29 Jun 2025 03:59:17 -0400) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 29 Jun 2025 03:59:17 -0400 > Cc: 78920@debbugs.gnu.org > From: Shawn Henson > > > On 6/29/25 1:13 AM, Eli Zaretskii wrote: > >> Date: Sat, 28 Jun 2025 18:04:07 -0400 > >> From: Shawn Henson > >> > >> 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? From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Shawn Henson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 09:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Robert Pluim Cc: 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175118865326715 (code B ref 78920); Sun, 29 Jun 2025 09:18:02 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 09:17:33 +0000 Received: from localhost ([127.0.0.1]:54800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVoAF-0006wi-RD for submit@debbugs.gnu.org; Sun, 29 Jun 2025 05:17:32 -0400 Received: from sender4-op-o15.zoho.com ([136.143.188.15]:17560) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVoAC-0006w6-VU for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 05:17:29 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1751188642; cv=none; d=zohomail.com; s=zohoarc; b=R2ZsGAh6ngYoiQZdnPb46XNbIOmgRDVtovORsZvRV2kMCEFTBdKQH7GwvXhgOBx3y8bDoA2PeBCoaiikKDfpdeIWdXEQYP1QdSpULWXkstUqCDZSphuZ0PZkXbXTmU+p0itIiT7RQTyWN5BJ9HkS/Gom5K2Ksf/OBEj4r0L/mcI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1751188642; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=ZDBGzk0B4vnekW/zjYVKX+NT4KCp0G0HpZx27xZz8/0=; b=SfPvQIdMC3pX6ccMFkN2nrRohWfdWyYHL4SxEbEvikpmAnoi8JGbuvT69PBscbnnIbhn4x8kue9OTMJm0nA4X+Qu9sszAKrdq9XuBWIH17aNTPqTzo02QjTAj2gOUP1+guJJ8hGx3m4nSuNQsIfHPdH/HHDh0BCJqgJHdsxPkCY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=shenso.name; spf=pass smtp.mailfrom=shawn@shenso.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1751188642; s=shenso; d=shenso.name; i=shawn@shenso.name; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=ZDBGzk0B4vnekW/zjYVKX+NT4KCp0G0HpZx27xZz8/0=; b=taXyquu6uedlYTnA2OxGSA4pmPW4Q6bYyRaAw219Tg20bkNNT/AvgjajhmzfOrUy eaxCfRzQnhmicjDSIX8ovQq07Kji732BsJJvh/OyJjQRuD/SHjxeZinR/oaRCBEMRKk oGGaQQo1L+3yAO97WIQHIcd60T2NNi6lNT3Cb8Q4= Received: by mx.zohomail.com with SMTPS id 17511886411421012.6918559060358; Sun, 29 Jun 2025 02:17:21 -0700 (PDT) Message-ID: <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> Date: Sun, 29 Jun 2025 05:17:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> Content-Language: en-US From: Shawn Henson Autocrypt: addr=shawn@shenso.name; keydata= xjMEaCEU5BYJKwYBBAHaRw8BAQdAjWuXCEe7ixkzRdRWLR+Iq4krQtuKZ3qbvyWNbNKU9dnN IFNoYXduIEhlbnNvbiA8c2hhd25Ac2hlbnNvLm5hbWU+wpkEExYKAEECGwMFCQlmAYAFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AWIQSYJumcFOWOyx5hquml6jo4WVLKCwUCaCIZ+wIZAQAK CRCl6jo4WVLKCyS3AQC0/NFzV1gC0PEdcWrt3uKvLPVNtFhYRH2VML6/Z/RPsQD/QLDHWwB6 sCFDLneQkusaCzlsTOdifhkyNiS4YEpuhgfOOARoIVrEEgorBgEEAZdVAQUBAQdAvCJlLX6A 6cBN+Xfr7EYJlf65MjFKszLe8TaLR5DCnF0DAQgHwn4EGBYKACYWIQSYJumcFOWOyx5hquml 6jo4WVLKCwUCaCFaxAIbDAUJAeEzgAAKCRCl6jo4WVLKC3I/AP96wvs/HdxdbCCICY32PFWD itXMPaDmiG9Jpj5jm1QNNgD9H8Ny8OYDUWeEeA2jkR2yL48ueTM7o30VvEMr3r6lwwY= In-Reply-To: <8634bj55bx.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 6/29/25 4:18 AM, Eli Zaretskii wrote: >> Date: Sun, 29 Jun 2025 03:59:17 -0400 >> Cc: 78920@debbugs.gnu.org >> From: Shawn Henson >> >> >> On 6/29/25 1:13 AM, Eli Zaretskii wrote: >>>> Date: Sat, 28 Jun 2025 18:04:07 -0400 >>>> From: Shawn Henson >>>> >>>> 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) ``` From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 16:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson Cc: Eli Zaretskii , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175121450719848 (code B ref 78920); Sun, 29 Jun 2025 16:29:02 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 16:28:27 +0000 Received: from localhost ([127.0.0.1]:58448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVutF-00059u-RW for submit@debbugs.gnu.org; Sun, 29 Jun 2025 12:28:26 -0400 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:46172) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVutC-00058H-9Z for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 12:28:23 -0400 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-450cfb790f7so29934455e9.0 for <78920@debbugs.gnu.org>; Sun, 29 Jun 2025 09:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751214496; x=1751819296; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=GqehFv+dG6xLPu1CXBBcJmF5pMeUQX4SwMps+HQHRMY=; b=MIEKsmQGApsccMekWlIPnDotIir9ONFyxfrj8KvFwvmk/uYApPiy8rXKsbq6rNua1N ISh8sEHiUp/mByUe0gO0zNusQblYafAtdE02Q1rxX9VINrtaB3JCZc/XNn8RuvxZNqEt ZksgFbu9DShBpdVSr6mWxhZxEsafA1n+Th6IbkqqnXDDS5hc8ZhszXHyjn3w3jg1rw1e Gla9mbvIcZ1Y/FN4yAiW98ma/l8sIUX1EKmwVnf5voSKdVC21XxFMNMhSztry33Ylw+Y yyq2DDpxaPqeosRL86frNIkXgcstxEXLdv5A6UQMJ2iFyZQgZD2UVWEOJ0LJ+v6f/JlA mWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751214496; x=1751819296; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GqehFv+dG6xLPu1CXBBcJmF5pMeUQX4SwMps+HQHRMY=; b=f2r0JHHsC0Z0b2zd07RA3h/lizEMNp5E1hPxXdgOCZsb6eNWCeIGyP/T4diLacizZe hqdHa3FWMaxoRbi6bzSEnUGVm6Ro64x9y++jKeSdTIV8ltA0mG9j+bui2woR3xWErwCt nG7wXidpMBQ1z9OhGSq0iDN5g9tg8pn8xgR0IjBYtMO6RIjoXlizPUNi5IuC1JgWBkpS cvEEHZxLvc8lJAwgT8OTa6RtGMiomZwuS+YcaFAUKQXbdWTxGT4pU3DQC8or79js6UgE 9+uzm1NvxT8l8W6LWEjBvQqrtLw01LAYAhXd44Z333nvJQkhtoIcRvUEoae2oryQwRFJ 5aHA== X-Forwarded-Encrypted: i=1; AJvYcCVuiYVVMSQFRPpPi+7cH7ZcCwKyOY4JpsyWUa/t7NHpG70F1nRnU0bqvznOdNW2e0IKNSyxkg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxCcx5bvIAkc3823iq1a1eeoeCmpEAIYY0t6cxsQr+qK43Fi1xk 0/qDwpF/mGg2oVZyx5swtLo44yGGYctvnk+lWwH3fNoT3mAYEep1WrvjE9VtHw== X-Gm-Gg: ASbGncsP4VSCLcoxCCcG4QYE3icODaoRXEjPwh3pWgTPGIlZHwS3wIZeAhMV76dO6OE GQFal8UJRSoAa16QuEJFSxBUT8No+h7EUBF5pNTIJ9r+3jjEPjR0LGDVcFXgN8+WSTjjkyRIvox q5g9txjVuwhSkaBGtcQYP31OkH5gPx1U7ds0aO+Io/QvdAvcF+SdYyGOnQ2HTk1lb+mrkGA0dt6 xvzoQSA7U/slb6aRZoWKLJXALeeY7R+0WLar6BGQE93K/PyDcpYjfJNh26GUigmkarTtIDZyxU2 CJkYDxkj7qT50MwuE8m82R3BmVQCYtfTPePguozCtCBRQpykog== X-Google-Smtp-Source: AGHT+IF01Gdn/6QWllpdp3dabLAkipnIh2TRrk2aX6cyKvgLs8HSjHfaHFBg/FhrJciJ98tH5JOx7Q== X-Received: by 2002:a05:600c:a48:b0:453:58e8:a445 with SMTP id 5b1f17b1804b1-45396a94e32mr46839475e9.11.1751214495425; Sun, 29 Jun 2025 09:28:15 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:8efb:eccf:f98b:f231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-453823ad01csm140205625e9.22.2025.06.29.09.28.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Jun 2025 09:28:15 -0700 (PDT) From: Robert Pluim In-Reply-To: <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> Date: Sun, 29 Jun 2025 18:28:14 +0200 Message-ID: <875xgeqzq9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Sun, 29 Jun 2025 05:17:18 -0400, Shawn Henson = said: >> 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?=20 For ":nowait nil", yes. Except in that case we should probably not leave a "failed" process lying around. Shawn> I see, though, interestingly if you are to run the `list-process= es' Shawn> you will see it persist there Shawn> indefinitely with a "failed" status.=C2=A0 And if you do kill it= , then the Shawn> process sentinel will be Shawn> called. Hmm, that seems wrong. When using async DNS, which we will only do for ":nowait t", Emacs will create the process, and then deactivate it upon DNS failure with a status of "failed". I don=CA=BCt think the sentinel gets called, but I haven=CA=BCt tested it. I wonder what Emacs does for ":nowait t" without async DNS, when the connect fails. I=CA=BCd expect it to call the sentinel with a "failed" status. Robert --=20 From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Shawn Henson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jun 2025 21:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: Eli Zaretskii , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175123217125134 (code B ref 78920); Sun, 29 Jun 2025 21:23:01 +0000 Received: (at 78920) by debbugs.gnu.org; 29 Jun 2025 21:22:51 +0000 Received: from localhost ([127.0.0.1]:60806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVzUA-0006XI-IK for submit@debbugs.gnu.org; Sun, 29 Jun 2025 17:22:50 -0400 Received: from sender4-op-o12.zoho.com ([136.143.188.12]:17256) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVzU8-0006Ws-4F for 78920@debbugs.gnu.org; Sun, 29 Jun 2025 17:22:48 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1751232161; cv=none; d=zohomail.com; s=zohoarc; b=kBC5BbJYWs0V/35+TwlUkFtHfTIbEZXPy8H7j25oGFEIQz3GuNk+VeetYDc/1cYwmAwYCJLHDVTf6WQi4CinznxRmn6zIxc5vxvYOkucauHjB5CHV1+2YRrRJfqTVB2rCLDK9v942mtyBB470fod2tmfiKt6q0TTW1v/bV8V0WU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1751232161; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=vSmCuuM/Zzm8li67PNha2N2oudpJ8tjqcB2behTBvBw=; b=ivgJV54j0+VBASuFFfANF0c6XFEBMedfp+V8/wOcuj0YCJ6xaYWVoKLZr4kq9bOpxGr2h/u3Rebp1/oqIq7vUX82WDybMRwql8zzzCfi5X3gdIUskdDwy3tflo1K5ad+43d7X3mGxXhtj2olCflISeNzKCWQcZxnTtwQOXE5toU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=shenso.name; spf=pass smtp.mailfrom=shawn@shenso.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1751232160; s=shenso; d=shenso.name; i=shawn@shenso.name; h=From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:Date:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=vSmCuuM/Zzm8li67PNha2N2oudpJ8tjqcB2behTBvBw=; b=ZQ9gg47Ik1x6s0xRSMR4AIA9ADIeFDhIPYMNU5WW0iVrBk5K/UrISezKk2l1vzs9 PEM0oogqJa1v5a//CglBjPdlztNKKrGzwRxhg3EBxXLuIHt1JK0P0tOfOXd4jBCRJud GHv3rVJQOH80l+5L4RuTd8qyiu4DCtsCucikB7qA= Received: by mx.zohomail.com with SMTPS id 1751232159228631.9902528012211; Sun, 29 Jun 2025 14:22:39 -0700 (PDT) From: Shawn Henson In-Reply-To: <875xgeqzq9.fsf@gmail.com> (Robert Pluim's message of "Sun, 29 Jun 2025 18:28:14 +0200") References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> Date: Sun, 29 Jun 2025 17:22:36 -0400 Message-ID: <87jz4udyzn.fsf@workbook> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Robert Pluim writes: >>>>>> On Sun, 29 Jun 2025 05:17:18 -0400, Shawn Henson = said: > Shawn> I see, though, interestingly if you are to run the `list-proce= sses' > Shawn> you will see it persist there > Shawn> indefinitely with a "failed" status.=C2=A0 And if you do kill = it, then the > Shawn> process sentinel will be > Shawn> called. > > Hmm, that seems wrong. When using async DNS, which we will only do for > ":nowait t", Emacs will create the process, and then deactivate it > upon DNS failure with a status of "failed". I don=CA=BCt think the sentin= el > gets called, but I haven=CA=BCt tested it. Sorry, I miswrote, I said "killing", but I meant to say the sentinel only g= ets called when *deleting* the process (manually, with `delete-process') after it has failed. Still, this happens after the process has been deactivated. > I wonder what Emacs does for ":nowait t" without async DNS, when the > connect fails. I=CA=BCd expect it to call the sentinel with a "failed" > status. Is there a trivial way to test this? Best, Shawn From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 08:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson Cc: Eli Zaretskii , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175127052412907 (code B ref 78920); Mon, 30 Jun 2025 08:03:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 08:02:04 +0000 Received: from localhost ([127.0.0.1]:38666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uW9Sk-0003Lt-Ej for submit@debbugs.gnu.org; Mon, 30 Jun 2025 04:02:03 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:52540) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uW9Sh-0003KZ-7s for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 04:02:00 -0400 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3a507e88b0aso1381525f8f.1 for <78920@debbugs.gnu.org>; Mon, 30 Jun 2025 01:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751270512; x=1751875312; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=W+3ukGvzTt3WRLtomGnt/O3fSM2BY6KvrrcHDVwy0sI=; b=hl6u/BcMrvPhVA+utLFJfcbxDPQ3FdqFhR1deVUP+NempOKG8WHDwRTlZWFlTXOZZe CjmdRvZ5pOXc9Hy4ryjGspB7ZgY3zmPSfGsAp5yodRgxD/KXEtVkJKbJ511TYDZOCBrk cSfL0twyWQ3Va/TMdG76ZO1OfSWL877+AsEpbkFrY2qo1jpvJ7dqKrzf50ornk+9aghN RfAodOqHjlPxxiSCDrygnn3RT1TLCsdBwgRL3S21+SY+0yGMkHN6vs9DUKtrU3gxxBZS iEFfBjzprc34S4gWLYG/62FdpwKZ5+FW+HzKIJX5uWWZEVxZEzgSy3+Su3mSpS01vL0O O9Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751270512; x=1751875312; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W+3ukGvzTt3WRLtomGnt/O3fSM2BY6KvrrcHDVwy0sI=; b=fM00JQuTSI3ClUW3LdT1L+b7JnXEBcdeJu3DhM8uioLDPC437MRK0rfUk+PIsw3cAu 1mmNEbXr/TnYKjb8B0FJmuQfA6YdHob+nHkjLYflJkOSgXRnEB9FQ2Oqb4P2rgubTT9T hRicFdyht+4dNI4OiJQ+8YXNZOJ/FOTrCyuI8qa/Xi+Rd5RWodTcO5DZB+4pmiHL2uEy Pr9TmbXwFvEJRPL5vp/qZMxvho6Y2OY9XvyaxigzXVAwXvbvpCi3U11dcdw4zcOnlkRd CyI959zkQtgDsNF9MCJiTFp2icPXEVLXsJhhVcl0M+NhjhDLPhUXPD1sx8VkCAbgjSrr AvKg== X-Forwarded-Encrypted: i=1; AJvYcCVCIuGFv1MPGgUky+L1KOqr3nlTheAW8ZrqSre4EjizEJaJxUXKKMtWDexVdbZ29EXHcKV64Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyqz2RVOHohw9LDOm6Q80vPZyZKL/YdW9l34s9j3lxBeoXn0ZJF aZM+PeDjeUiPM2PCDGMr8wN/wE9ZEVzQBf0I+cC+Kjr+shycO/Y/xjdnmEOfzw== X-Gm-Gg: ASbGncveZrewWcbRVOfaiTNHAl8krMiRTHOeszexrdnLX8W5nbU5WU9XKdM66lcphJ3 lQfY64XTElX1hlmQoZeGOHBIcwaYAQyLviA7w+VY5vm/bqe4Ze3Q0+GilFLbsm+H/Jvg1ZfhUeG ZbK4XyLtUn69AT295ZRxOEUue4h/j2Qnc/lj7ZDRaG6SihgEWW0PBiFx14Zq/1syLVGhOs0cb8E 8W/mtg8REuHawOKSoG+W5sXW1rDNH7n/Lc2hn9blIU+xkLEaGKGm1nsQfF3FjwTUJhURhWC7bFA CVu1VjYe2upjWZrDczZTLusSGs9YaiUxAq57iKuYNy47gjyv0A== X-Google-Smtp-Source: AGHT+IGnLpmWiIgM3W08w58uODFqrmqXP67rTVpTCKBtCUjt3S16XLaPLzc+wwmn1I+nugSSbv/tkQ== X-Received: by 2002:a05:6000:2082:b0:3a4:ef8e:b31b with SMTP id ffacd0b85a97d-3a8fda34eebmr9659827f8f.24.1751270511983; Mon, 30 Jun 2025 01:01:51 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:8efb:eccf:f98b:f231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a88c7fa54dsm9545201f8f.23.2025.06.30.01.01.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jun 2025 01:01:51 -0700 (PDT) From: Robert Pluim In-Reply-To: <87jz4udyzn.fsf@workbook> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> Date: Mon, 30 Jun 2025 10:01:50 +0200 Message-ID: <87sejhpsi9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Sun, 29 Jun 2025 17:22:36 -0400, Shawn Henson = said: Shawn> Robert Pluim writes: >>>>>>> On Sun, 29 Jun 2025 05:17:18 -0400, Shawn Henson said: Shawn> I see, though, interestingly if you are to run the `list-process= es' Shawn> you will see it persist there Shawn> indefinitely with a "failed" status.=C2=A0 And if you do kill it= , then the Shawn> process sentinel will be Shawn> called. >>=20 >> Hmm, that seems wrong. When using async DNS, which we will only do f= or >> ":nowait t", Emacs will create the process, and then deactivate it >> upon DNS failure with a status of "failed". I don=CA=BCt think the s= entinel >> gets called, but I haven=CA=BCt tested it. Shawn> Sorry, I miswrote, I said "killing", but I meant to say the sent= inel only gets Shawn> called when *deleting* the process (manually, with `delete-proce= ss') Shawn> after it has failed. Still, this happens after the process has b= een Shawn> deactivated. If the view is that we didn=CA=BCt call the sentinel because the DNS failure means we didn=CA=BCt create a process, then we shouldn=CA=BCt call = the sentinel when we delete the process either. >> I wonder what Emacs does for ":nowait t" without async DNS, when the >> connect fails. I=CA=BCd expect it to call the sentinel with a "faile= d" >> status. Shawn> Is there a trivial way to test this? Not without recompiling Emacs, but I=CA=BCve 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=CA=BCs all as expected (now that I=CA=BCve had my coffee =F0=9F=98=80). 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=CA=BCre deferring the DNS lookup. 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). Robert --=20 From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 12:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson Cc: rpluim@gmail.com, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175128608423934 (code B ref 78920); Mon, 30 Jun 2025 12:22:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 12:21:24 +0000 Received: from localhost ([127.0.0.1]:42075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWDVj-0006Dv-TP for submit@debbugs.gnu.org; Mon, 30 Jun 2025 08:21:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49198) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uWDVh-0006Cp-7u for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 08:21:22 -0400 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 1uWDVb-0004GO-IQ; Mon, 30 Jun 2025 08:21:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sgd7YFVSCSZIhPcpcVT0U66TAo2XK8sSOQf7rnf8BF4=; b=K1w5z1UXHJ/WoSZdp8P4 Jmhg+NDwoq8NuMUV804c9fh+9D//xkjp3xhyxGSdIbHw+jYx5Hpdzf1beqAyzLKIPU48zvadXehBl 2QjOMw9X5Up7aFxVeATRo6nX22BcNsFdI8zA7p+VBYozP30IC8t+GBRL5p7IXWg6Tk3BfK4NUEsoQ Ct69NaVuGP9yp40OzIbUllBv56coR3Fp8onCVAnWxaiQbTGSbJnAS80NH6X0MGgLmgit+UgojcBh8 sMW1fOeTwh5+2gQbtbs573P7VsvMGfGVO9qLzhJR10FexKMAyUfXAuN05Qy56Y6kmyZH/BwsY9tcK laWqPzvcsCTioQ==; Date: Mon, 30 Jun 2025 15:20:53 +0300 Message-Id: <86ldp94dzu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87jz4udyzn.fsf@workbook> (message from Shawn Henson on Sun, 29 Jun 2025 17:22:36 -0400) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Shawn Henson > Cc: Eli Zaretskii , 78920@debbugs.gnu.org > Date: Sun, 29 Jun 2025 17:22:36 -0400 > > Robert Pluim writes: > > > 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. > > Is there a trivial way to test this? Run the recipe on MS-Windows ;-) The result is that we signal an error: Debugger entered--Lisp error: (error "thisisnotarealhostname/80 No such host is known. ") make-network-process(:name "dns-fail-test" :buffer "dns-fail-test-buf" :host "thisisnotarealhostname" :service 80 :nowait t :sentinel #f(lambda (process event) [t] (print event))) (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))) (progn (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)))) eval((progn (let ((my-test-proc (make-network-process :name "dns-fail-test" :buffer "dns-fail-test-buf" :host "thisisnotarealhostname" :service 80 :nowait t :sentinel #'(lambda ... ...)))) (message "process status: %s" (process-status my-test-proc)))) t) and there's no process shown by list-processes. From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 12:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Shawn Henson , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.17512875924081 (code B ref 78920); Mon, 30 Jun 2025 12:47:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 12:46:32 +0000 Received: from localhost ([127.0.0.1]:42402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWDu4-00013k-2G for submit@debbugs.gnu.org; Mon, 30 Jun 2025 08:46:32 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:43245) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uWDu1-00012o-IG for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 08:46:30 -0400 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3a4e742dc97so3412275f8f.0 for <78920@debbugs.gnu.org>; Mon, 30 Jun 2025 05:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751287583; x=1751892383; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=47AFtSBUcjOpES/Hs7oKfEYqQeFUyY9Q188GNVbz4Ec=; b=eKoHsinfmjfynK7BaRaT5yUFoZP8kD7QUyidtC/sscD9E52QBMrApn3oNwDzVSNCXj RN2LsnNW5hVX/N/EKMf/ZbGMwmLRut6BJKuAQsjCIzAH8Ue/tqHlBdfJ/brvdtmAWHSI kW0+F5WAj8ipa6Pfpy44AVQ7UIzebT4Hk0FSpKaQn5/ie33tcJaA/ikGdTDnp/sAwQhb d0zJ4rhgJpz6TZGrphIp7EWkyuQwf0RJS/rZttVZULc0oSucdYgGpdlsnubrJJGrSok3 ZPZbP3tXWKW/CplGetfzlkzJinNdtsrD3GdZY+a/tRnD5MSIdvOKkRJU4BLo0ZFr4+m3 8i4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751287583; x=1751892383; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=47AFtSBUcjOpES/Hs7oKfEYqQeFUyY9Q188GNVbz4Ec=; b=BPnp6WxmXI1eDeCftV+RsDejM1A8g0jAbJww4iT/Y9YawOfi2qCZrsCSd+Eo/36gJs 5EeSLMe5Wka9Nq4agMvqHrWzXOoguPk70Xn28sFFRUv/9sqOKuwITvsOKmgSm6B7rsXG L0LgnkHo6VUgimTTerBJE1a5UNku3/LQvsKwrLDWr6YOIHT7Jz8m6y3oa5Vvcj1Ifccl fY4VwAStNHR4qvvIEGYFYWNxBp6MvBd2Q/+XK2QCFTn7cnsVrghufgw6KttzvHJAxUtD YoYLoT0OoZLXaXE1G/0gFo0X8diT2vtkSuInEXQaCKW0Pe0TPC+g+qY5fz+uhx4JMLxx dAsQ== X-Forwarded-Encrypted: i=1; AJvYcCUYf1LXfp4JYHV1LxcU/tqBiFhiUZ5rKeEZuf6avv6IFHxReafwRipYO2ix4/bC2bzj42EzIA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwD6/IjPm2WIrncc9Y7hWh2YCTuV7IPwW7dRV4UXIYwKqOTZqtl iA/LxfzdcXWkRjN3AepGNmw7THi50RnpAPrHuYPERDuZtUTyCxPv6+Ogdowx7A== X-Gm-Gg: ASbGncuhTeLU2r5xvjzmknckK+31b0q9DX6YfikAglEmuhR5CkGTxsLx1NnYsF/ukoR dOxdr7OoYi8HjC6QKIXYrV6y5XvokYEEoYsFnJ9s/E6+riUH1lOI7zD4XTSFGjRfHQyHsGgTjEe GrsvvtPf7AtO0f+keW4j5eyuca2JsgEuALJYD2KUxe/6ep00v2ZCJq7btS/qvAYwwzDt8TcLlYG TkeJ9lh8KJjypW14Nh/HHQlkzgzY873qWl+lV2A9kzXMDxgodgy2fLiTu1zmyxYUn/5yUY1a3kM AdrpM2vxs/hr4wRdc8hmQUQquap7Xa2qbyhrMU6oHK1Cz46aeA== X-Google-Smtp-Source: AGHT+IHNnEdxlZJ1n0DJSU/nGO+BFAceNQuSEWtZwx3kte3yGly30gYceKTrwarwcZTiKMele5dt4Q== X-Received: by 2002:a5d:5e89:0:b0:3a4:f7e7:3630 with SMTP id ffacd0b85a97d-3a98b53f383mr10671528f8f.15.1751287582672; Mon, 30 Jun 2025 05:46:22 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:8efb:eccf:f98b:f231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a88c80b5a3sm10250138f8f.40.2025.06.30.05.46.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jun 2025 05:46:22 -0700 (PDT) From: Robert Pluim In-Reply-To: <86ldp94dzu.fsf@gnu.org> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <86ldp94dzu.fsf@gnu.org> Date: Mon, 30 Jun 2025 14:46:21 +0200 Message-ID: <87jz4tpfc2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Mon, 30 Jun 2025 15:20:53 +0300, Eli Zaretskii said: >> From: Shawn Henson >> Cc: Eli Zaretskii , 78920@debbugs.gnu.org >> Date: Sun, 29 Jun 2025 17:22:36 -0400 >>=20 >> Robert Pluim writes: >>=20 >> > I wonder what Emacs does for ":nowait t" without async DNS, when t= he >> > connect fails. I=CA=BCd expect it to call the sentinel with a "fai= led" >> > status. >>=20 >> Is there a trivial way to test this? Eli> Run the recipe on MS-Windows ;-) Eli> The result is that we signal an error: Eli> Debugger entered--Lisp error: (error "thisisnotarealhostname/80 = No such host is known. ") Eli> make-network-process(:name "dns-fail-test" :buffer "dns-fail-t= est-buf" :host "thisisnotarealhostname" :service 80 :nowait t :sentinel #f(= lambda (process event) [t] (print event))) Eli> (let ((my-test-proc (make-network-process :name "dns-fail-test= " :buffer "dns-fail-test-buf" :host "thisisnotarealhostname" :service 80 :n= owait t :sentinel #'(lambda (process event) (print event))))) (message "pro= cess status: %s" (process-status my-test-proc))) Eli> (progn (let ((my-test-proc (make-network-process :name "dns-fa= il-test" :buffer "dns-fail-test-buf" :host "thisisnotarealhostname" :servic= e 80 :nowait t :sentinel #'(lambda (process event) (print event))))) (messa= ge "process status: %s" (process-status my-test-proc)))) Eli> eval((progn (let ((my-test-proc (make-network-process :name "d= ns-fail-test" :buffer "dns-fail-test-buf" :host "thisisnotarealhostname" :s= ervice 80 :nowait t :sentinel #'(lambda ... ...)))) (message "process statu= s: %s" (process-status my-test-proc)))) t) Eli> and there's no process shown by list-processes. Yes, in retrospect that makes sense as a behaviour. But we can=CA=BCt do that with async DNS + :nowait t. Something like the following perhaps? Although I think the sentinel still gets called when you delete the leftover process, so probably more is needed. Robert --=20 diff --git a/src/process.c b/src/process.c index e61ec425f7e..473d8294a88 100644 --- a/src/process.c +++ b/src/process.c @@ -5172,6 +5172,7 @@ check_for_dns (Lisp_Object proc) concat3 (build_string ("Name lookup of "), build_string (p->dns_request->ar_name), build_string (" failed"))))); + exec_sentinel (proc, build_string ("Name lookup failed\n")); } From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 12:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: shawn@shenso.name, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.17512880067346 (code B ref 78920); Mon, 30 Jun 2025 12:54:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 12:53:26 +0000 Received: from localhost ([127.0.0.1]:42493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWE0j-0001uQ-PA for submit@debbugs.gnu.org; Mon, 30 Jun 2025 08:53:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41454) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uWE0f-0001t4-UR for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 08:53:22 -0400 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 1uWE0a-0000uh-1o; Mon, 30 Jun 2025 08:53:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ReHqCuheQfSohusqwsFnC6vgkrdMDBXF3uKLZbGzBPI=; b=lQJR6vWIXeECthfY1TlX m8+47uwJSuhJwdMleuylzxLAF+uP4TR5r0y5uosoQ4oNcAB4RVStMHmndEfhHx5U7bPoD4JuClnIi yDqa7NYFUSjRodxLm/+RxsKMao3P0vR6pjPWc7ksmzsfzizhNjj81OS036g7K6nl+TQupGKbXnFS6 SzjD930h4ZfyAQLTwhIR3WOZjWiQq1bRZUb2ISW12Itj2VfrZayrz7mruOKl1fr57IDnyXoXHptBG NwCzla0lBQZQS5K6k87AnGAR25ayZxUSLzEP6qjQHe8YjZE3jFj1Vp+VMfnkurnQ7WK5GLcphQS6b 1/VRH8Ym1fF4iA==; Date: Mon, 30 Jun 2025 15:52:45 +0300 Message-Id: <86frfh4ciq.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sejhpsi9.fsf@gmail.com> (message from Robert Pluim on Mon, 30 Jun 2025 10:01:50 +0200) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: Eli Zaretskii , 78920@debbugs.gnu.org > Date: Mon, 30 Jun 2025 10:01:50 +0200 > > >>>>> On Sun, 29 Jun 2025 17:22:36 -0400, Shawn Henson 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. From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 13:13:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: shawn@shenso.name, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175128917917007 (code B ref 78920); Mon, 30 Jun 2025 13:13:03 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 13:12:59 +0000 Received: from localhost ([127.0.0.1]:42742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWEJe-0004QB-V8 for submit@debbugs.gnu.org; Mon, 30 Jun 2025 09:12:59 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:44377) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uWEJc-0004PC-Gm for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 09:12:57 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-451d41e1ad1so29147425e9.1 for <78920@debbugs.gnu.org>; Mon, 30 Jun 2025 06:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751289170; x=1751893970; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=xN7W6HxvWYeUdhgwPKaK+OCS4oVAqauGtNOBBNR4Teg=; b=Q8PM/alFG96zxxp73/n3yZ9NbesWEl9tM6yECFpc2B7i3Jfk5nfyeLbBRZgSlKIeIJ bLLEKeqYqoaz7BlQgKSp4wEqataykxH1TK0/gHq0dtba75W5m7ERZZGQ7FNXGJsLpxuh nJC6hiEJ4wXk/d5AEuAFN0m1FuFhp0jYfxElfpis6Kd78sV1aDmugAWjNYMq4oxmgEFR WYN0lklSLwuztL3nchQ/wbBzul2Fap3uv7UWe9luBulZK+IaJLf/9H64ATOYgZeQGWJK ga9XzV0n4ZVo6qPcLIJ+2hylEwTev8QJiw2Ln8e2Sb727CiZRXNpSlu19tUYXBQLWwbN xo+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751289170; x=1751893970; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xN7W6HxvWYeUdhgwPKaK+OCS4oVAqauGtNOBBNR4Teg=; b=VddiTJVmydOJ3PJyEiFGqUrkrufUFCHSQ9R1Yj73iot3aLzmh4TzukRKA8m9ODeVB/ v0RMuc9QsimrhiDHUVWi8Xf2xWtvdctIRHo2/RjSEwRx+lciI6sCtrg3w5XV1Epwj6h7 EPuagii9e46OkSWZ0qdh1GRP2JUQx+yEtretv0O81wHkQwbZhnYCVKURqb3ipSbViu0F 9qyaI2Spl7tONQFIvuBHjlbw7ZqZE7z6oIWeTcFAZ2ZniKlI7ghdCi/Q2TcAmIo6uhAN SjNFIN5TCqUSr5pArzGal4K4vzBsoYiuVEpD9p0tB/YGjpgViD6QO0lzCgTHpE/3iSe/ 45UA== X-Forwarded-Encrypted: i=1; AJvYcCUpr+ZEIzwOMWCaUk7bjhgoCF5GnHsYbCwySWqdB/PlMl9v08iNadg6AB0F20eYKKSVW28nNA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxRUmh/5pivXOJ2GvfzEzwhzX9RB7GxTfRco15DAnwxF5Wq2D7L aVCFptFm7zWEy90aebEakkXzmAajO2AIKf1FZL4kSOCWYDuSWQxxOXJnA5xU9g== X-Gm-Gg: ASbGncuJNgeQuPMbrEER4tNy323Gal21K8ivB0p9utkIZ3pISLoXZ2RdLYSXZE5U+IB NjDIPzeKYHeG6jNlL1Nty6YKxGi19LeE02Gjq0KijYyJgFFcYQl/67eOGPXhuFe+6aXmuc6QNW2 zuYHyQdi4RoR9MqJkSKfgIQTjrbWFT8kdfDd8AvIQtqxyaIJpTYnGPRafpz+MwN0fZV4SYTQU5b knA2QIQGDw6CJHhibrvnFrpZ4c2ATs5pH38sAS/FnE4m4CaKbVCiH+ji7VEN/i3IQgjRSRp2b8a FnJuEs0zK/I6n6fkB5ibJ+iqytSILloviltcwc8dbAj9Q6b9Cw== X-Google-Smtp-Source: AGHT+IFOEE3w+6APLS1CrSf9+f5p2VUoj3wtjDuV6dJKWhO7bPLGLav9DY3/iWj7v91t7ckh9xig2A== X-Received: by 2002:a05:600c:524f:b0:450:cac5:45e7 with SMTP id 5b1f17b1804b1-4538ee5008dmr127438495e9.1.1751289169643; Mon, 30 Jun 2025 06:12:49 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:8efb:eccf:f98b:f231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-453823ad0f3sm168408425e9.19.2025.06.30.06.12.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jun 2025 06:12:49 -0700 (PDT) From: Robert Pluim In-Reply-To: <86frfh4ciq.fsf@gnu.org> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> Date: Mon, 30 Jun 2025 15:12:48 +0200 Message-ID: <87frfhpe3z.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Mon, 30 Jun 2025 15:52:45 +0300, Eli Zaretskii said: >> 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=CA=BCre deferring the DNS lookup. Eli> If we want the same behavior, we should signal an error when DNS l= ook Eli> up fails. OK >> The docstring for `make-network-process' says this in the :nowait >> section: >>=20 >> the sentinel function will be called with second arg matching >> "open" (if successful) or "failed" when the connect completes. >>=20 >> 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). Eli> But then the behavior will not be like we get when getaddrinfo_a is Eli> unavailable, no? True. Then the semantics would be "we couldn=CA=BCt create a process because DNS failed" in both cases (and the sentinel is not called). I wonder if doing it the other way would be more in line with people=CA=BCs expectations: `make-network-process' with :nowait t always succeeds, and if there=CA= =BCs a DNS failure the sentinel is called with an error. After all, :nowait t is the caller asking for asynchronicity. Either way, Emacs=CA=BC behaviour changes. Eli> Technically, we have no process object in this case; the fact that= we Eli> create one is an implementation detail. I'd even go as far as say= ing Eli> that this "process" should not be exposed to Lisp. Then we=CA=BCd need to split `make_process' between creating the C-level process object, and adding that object to `Vprocess_alist' (I hope that would be enough). And we have to expose it to Lisp in some form, since `make-network-process' returns a process object. Robert --=20 From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: shawn@shenso.name, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175129060229430 (code B ref 78920); Mon, 30 Jun 2025 13:37:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 13:36:42 +0000 Received: from localhost ([127.0.0.1]:43106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWEgb-0007eT-0b for submit@debbugs.gnu.org; Mon, 30 Jun 2025 09:36:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57640) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uWEgX-0007dT-Fm for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 09:36:38 -0400 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 1uWEgO-000139-0T; Mon, 30 Jun 2025 09:36:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=GeFR6r1hw1J6tck3ZWJnbQbNUmImtlR8HIRq/+uw+Xk=; b=XCVXqC5dCms0pdXE8WhD jgx+FHKcL5nUm234Cj1maSpIYZDEmkKTUrruY3KuTCMh1IbWZ/rZfKhzLYSj7QTTTffnLMGDm911i zns/hbd6u39jXrNJhovxZ6abQkPTvflMDiwRvxZ506p6/NoWV3Y4L13c9zOV0F/XeA3a3UcPOlw0G O4mbqbsGtexxrVKJmXe6HrGZ5CVSjq/SJdt4OFb0RTDEVLZV99UmnHxNz3ZDK8whmsXnNq0yHUPCV +oEJtS6GhoOH4y6JOctg5RhPChZOHBRbY0oZYqItqnVO3txGmOdzWJS61xyC/fNNpLZ3KP/HMI54u Tqh1oKf99MTuGA==; Date: Mon, 30 Jun 2025 16:36:24 +0300 Message-Id: <867c0t4ahz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87frfhpe3z.fsf@gmail.com> (message from Robert Pluim on Mon, 30 Jun 2025 15:12:48 +0200) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> <87frfhpe3z.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: shawn@shenso.name, 78920@debbugs.gnu.org > Date: Mon, 30 Jun 2025 15:12:48 +0200 > > >>>>> On Mon, 30 Jun 2025 15:52:45 +0300, Eli Zaretskii said: > > >> 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. > > Eli> If we want the same behavior, we should signal an error when DNS look > Eli> up fails. > > OK > > >> 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). > > Eli> But then the behavior will not be like we get when getaddrinfo_a is > Eli> unavailable, no? > > True. Then the semantics would be "we couldnʼt create a process > because DNS failed" in both cases (and the sentinel is not called). I > wonder if doing it the other way would be more in line with peopleʼs > expectations: > > `make-network-process' with :nowait t always succeeds, and if thereʼs > a DNS failure the sentinel is called with an error. > > After all, :nowait t is the caller asking for asynchronicity. > > Either way, Emacsʼ behaviour changes. > > Eli> Technically, we have no process object in this case; the fact that we > Eli> create one is an implementation detail. I'd even go as far as saying > Eli> that this "process" should not be exposed to Lisp. > > Then weʼd need to split `make_process' between creating the C-level > process object, and adding that object to `Vprocess_alist' (I hope > that would be enough). And we have to expose it to Lisp in some form, > since `make-network-process' returns a process object. We could give the process a special attribute, and make Lisp APIs skip it. But maybe calling the sentinel will be easier and less drastic? We just need to document that the behavior is not identical to the systems where async DNS resolution is unavailable. From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2025 15:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: shawn@shenso.name, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175129681817001 (code B ref 78920); Mon, 30 Jun 2025 15:21:02 +0000 Received: (at 78920) by debbugs.gnu.org; 30 Jun 2025 15:20:18 +0000 Received: from localhost ([127.0.0.1]:45472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uWGIq-0004P7-GH for submit@debbugs.gnu.org; Mon, 30 Jun 2025 11:20:17 -0400 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:60515) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uWGIl-0004Mb-8u for 78920@debbugs.gnu.org; Mon, 30 Jun 2025 11:20:13 -0400 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3a510432236so1670347f8f.0 for <78920@debbugs.gnu.org>; Mon, 30 Jun 2025 08:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751296804; x=1751901604; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=hdndrGK8nXhMAf+eppxq0bqC6YelMVu/NgHzCtM+NQM=; b=HWRfKFiY6dZT1TqlCPIln9y0lnBUlTmHaHr8Ua0YJxxrGH6EvH7F7NwpLtGK8rNFJw oLiXZxUchGYCG+BXtCbJ4YlY2+bky0r9wYW1xE+LzhVQsGe7ApCmpLzduGUsMtQyNhQm Dj6hsHcQ8V9i3FkQA3CPKqmrwYagCOFTB8wz2Go7oEEK7hG9BxdjNoNbgBoF6eynqQvM VRlHUhnc4GyzYrwqklpy807UDUvmb9A2iMkaJoqsPtVciqqh6lCCOgm6zzwRrMpwSksG Bc3a+Sn4cdGv9aPsLFFlPoudDWm/U75HMQgNKzfYPUCKZZ7i1/ZHnJNEsr6mheWzUCT8 RcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751296804; x=1751901604; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hdndrGK8nXhMAf+eppxq0bqC6YelMVu/NgHzCtM+NQM=; b=v3bvq62QB1JFSlSJe3aiEkfFEyXgZwJIKtBtmqW6DGEPCcdy4nGTuYO96y0DMsZCU7 /BQWIOZSbR7xTERm2jYJJwnGi8z5D8hTxghdzEtqciz/5KPGONFSSFie5kdGrACBUN0k U/jqn/2Eedh280ufuxqXuKk2w+ExUfwrQAI54ODmL4zdpCvB5UFYUt/GSET2kbXIVWUk VlxA2VoHdu5J8+zvNfYabjD0iRupszTifl6bEw3NQy9tlAjuLq813WwPn3hAgpN0MRG8 PWoKsm98GefuEXK/j9TMYCvNZ9BJhjXqSIn4iagQXk7qC7JwVBKyyRvGY2kV1kAOpRpS BrHg== X-Forwarded-Encrypted: i=1; AJvYcCX996ntp43dHKVF2FURxWPQCF5tQoM/LMHAZJR6AAb6D25GWo9s0okwLSny6Ox4jsH3iSDmCQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzCHHs4hGSxbBvjn2Plk5Ku8u3O3gQIr/3KWiV8tzvKAvFW9JC9 vsuhx86/Sl+K7tcU3pAK54fhxowkt+ZU//AwKIEYPe5js880Y5BqT5vGOhGgpQ== X-Gm-Gg: ASbGncu1Exmf7eYUS5KO3q3LyRGGmOv5mpIobkudMiCPV8mh3300OYiKAfsGmxbpjSB tAbrH+Y+Ze6TQ3SYrVHmIU5KDK77d/kb4xgZu2tSS4FScKId+blWNCBEp5l9Zb1RIsdQ+rrvozq /pHY/YYZAiZAYFebV5AihgMqUzK4yJwfMFvMAc+9puLfMY6KFN5Cr7hpScNCr4D+DQGU3LnACkC /eITmfEKtJVCr/ZsDzzcrCJAPrKF/Os4cC1tADJYa3sJ/ysBSmLT6RQ3Tg20VMuPz8nOaj+Ip1H o63dh77uxEyLO++I1AXoLJFGFMAvYQMbV0S90OrE0l94QFW9Qg== X-Google-Smtp-Source: AGHT+IGy9jQnDFXAzK+0VEd4/lx4ExBbtPEKijvcNKm/09Rp8nd5yKGm4W3De3ox22DrpR3VaL7xUA== X-Received: by 2002:a05:6000:2082:b0:3a6:f2d7:e22b with SMTP id ffacd0b85a97d-3a8f482ce2dmr12270590f8f.18.1751296803836; Mon, 30 Jun 2025 08:20:03 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:e892:5a81:fc89:b4dd]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a88c7facb3sm10761833f8f.30.2025.06.30.08.20.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jun 2025 08:20:03 -0700 (PDT) From: Robert Pluim In-Reply-To: <867c0t4ahz.fsf@gnu.org> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> <87frfhpe3z.fsf@gmail.com> <867c0t4ahz.fsf@gnu.org> Date: Mon, 30 Jun 2025 17:20:02 +0200 Message-ID: <87bjq5p87x.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Mon, 30 Jun 2025 16:36:24 +0300, Eli Zaretskii said: Eli> Technically, we have no process object in this case; the fact that= we Eli> create one is an implementation detail. I'd even go as far as say= ing Eli> that this "process" should not be exposed to Lisp. >>=20 >> Then we=CA=BCd need to split `make_process' between creating the C-l= evel >> process object, and adding that object to `Vprocess_alist' (I hope >> that would be enough). And we have to expose it to Lisp in some form, >> since `make-network-process' returns a process object. Eli> We could give the process a special attribute, and make Lisp APIs = skip Eli> it. I think that comes down to the same thing as not adding it to Vprocess_alist until DNS has succeeded, which is easy to do, I=CA=BCd just have to make sure it gets added to Vprocess_alist at all the right spots. Eli> But maybe calling the sentinel will be easier and less drastic? We Eli> just need to document that the behavior is not identical to the Eli> systems where async DNS resolution is unavailable. There=CA=BCs a third DNS failure case I just noticed. With :nowait t we can get 1. An immediate failure of async DNS 2. A delayed failure of async DNS 3. An immediate failure of sync DNS In cases 1 and 3 we return an error, in case 2 we set the process status to "failed". The sentinel is never called. So calling the sentinel in case 2 changes the behaviour, but that behaviour was already different, and then it would match what happens if the remote host exists but eg rejects the connection. The semantics are not really documented, so I guess we can change them =F0=9F=99=82 Robert --=20 From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Shawn Henson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jul 2025 19:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: Eli Zaretskii , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175243327718983 (code B ref 78920); Sun, 13 Jul 2025 19:02:01 +0000 Received: (at 78920) by debbugs.gnu.org; 13 Jul 2025 19:01:17 +0000 Received: from localhost ([127.0.0.1]:55504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ub1wp-0004vz-MT for submit@debbugs.gnu.org; Sun, 13 Jul 2025 15:01:17 -0400 Received: from sender4-op-o12.zoho.com ([136.143.188.12]:17295) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ub1wm-0004vn-Ik for 78920@debbugs.gnu.org; Sun, 13 Jul 2025 15:01:13 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1752433257; cv=none; d=zohomail.com; s=zohoarc; b=ijwGzSXfoq3FhqgUrpz14eVDu3bSCmIl1JLEzJMdPMfgGM/spfxTOoZI40l3CKG+cz8y73HfQ7xpPrZppSHhB8QFBLdTMXHLWbi2NYZVXDKosYADKexGDJHCNqrTv0Sowy9Wink9m4OoXDfvD48vvCIRknFGC/JkcMcs3tkHXUE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752433257; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=o0YfIooXqoIniSFxuOAncF/LlRmlFeIKpIhwxwYvXjw=; b=dmL6514jWcj+KF4Mw5VrBFL/m3/q6bLLlzsY+kYz6Db4YM0ChpYXgQlHXAHBMr7pZ/qzGkMJRginsR0/3aiovySOqTYR4LZ3L1BwMDtHE89xdY53FpXqfrfTlpfAEkB+MkHVX6GU4oVaSi5oqyv9RplS7smtWB/DK7PvUvcBcdQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=shenso.name; spf=pass smtp.mailfrom=shawn@shenso.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1752433257; s=shenso; d=shenso.name; i=shawn@shenso.name; h=From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:Date:Date:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To; bh=o0YfIooXqoIniSFxuOAncF/LlRmlFeIKpIhwxwYvXjw=; b=XSa83E6S6dP2varzeWl6gR0BNhnGcZTGFpkUAyMP+okalSa0dT9Q23KHcu56bAst 9drrOJ+5NZDuRPX7DCHC+ykgQzhYggybYyEbo3zjqw6PGO0wcHhHW9gMdwL/+XutjaB XnejEgC1gukDQyIiCLsrTCE3nWZX4J/7Klz7JVIM= Received: by mx.zohomail.com with SMTPS id 1752433255026185.22637675547412; Sun, 13 Jul 2025 12:00:55 -0700 (PDT) From: Shawn Henson In-Reply-To: <87bjq5p87x.fsf@gmail.com> (Robert Pluim's message of "Mon, 30 Jun 2025 17:20:02 +0200") References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> <87frfhpe3z.fsf@gmail.com> <867c0t4ahz.fsf@gnu.org> <87bjq5p87x.fsf@gmail.com> Date: Sun, 13 Jul 2025 15:00:51 -0400 Message-ID: <87a557hq58.fsf@workbook> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External X-Spam-Score: -1.0 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) Hey y'all, If either of you are American then I hope you had a nice 4th. Just wanted to check in and ask if a decision has been made regarding this bug. > So calling the sentinel in case 2 changes the behaviour, but that > behaviour was already different, and then it would match what happens > if the remote host exists but eg rejects the connection. If calling the sentinel is the agreed upon solution, I may be willing to help if you think it would be a good first contribution. Best, Shawn From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jul 2025 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Shawn Henson Cc: Eli Zaretskii , 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.17531081897641 (code B ref 78920); Mon, 21 Jul 2025 14:30:02 +0000 Received: (at 78920) by debbugs.gnu.org; 21 Jul 2025 14:29:49 +0000 Received: from localhost ([127.0.0.1]:57572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1udrWX-0001zA-1k for submit@debbugs.gnu.org; Mon, 21 Jul 2025 10:29:49 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:50395) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1udrWU-0001ye-7r for 78920@debbugs.gnu.org; Mon, 21 Jul 2025 10:29:47 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-455b00283a5so26456125e9.0 for <78920@debbugs.gnu.org>; Mon, 21 Jul 2025 07:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753108179; x=1753712979; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=cUb7gy0fwuBX2k/TaNXKu9AugG94c5Vm8PvDfbjKjWg=; b=Oq0z1m0gnLi4YaIOROx1xe7XBPo1Cdl87HChkn1IHMp2nBX2YqGVyo9CQd8dq/OIjW tjOeFaetAQXq4WT1G7eU0zRELeRGn99eZBODUt055ZG/Ozng9kPmWoOeefiCwDWt+XVu Mi9NzbbUEnzoN905JvoLDsMvmvhKMtKyNFIouzTIGbY+RQCHb7HX0HycW6m5zpXOuKrT O+ZhjBhCkxv9xGn3/zDilpQlNrzsBxjiNVusMhInsLng9Lp+ssjke8rCjx8aRPv7vrev UYN0gimIETxGi9C/d2WT5tlLVlytHN9fU9jXXkGO9nMDiolV1mBaEHuGYBGS4h7biKda TQ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753108179; x=1753712979; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cUb7gy0fwuBX2k/TaNXKu9AugG94c5Vm8PvDfbjKjWg=; b=xUIHunpJ3gt4i7hjgB124j/abnwFS2Tzq1bShigjnLGHmpVF3k6lqMujW6g71Xtuz1 nTctkkYNFzyo9quflfb/rCoGAiwIihpb/Tp61zHrRPW2k9HZivONe6+I11VTxLOTuwjH csp0EuRqMBZEvVNtkQy+KN++cmadBEgYoN/P+j51zu1kJ8Ki/V0AobTuw/K4TREnqkjg 70OE8U56IJYouTsTs4A9hox4dGUHscXZbrx9klQCvUiejCx/uCatcFQkiH1m2B3C0H7g jaNrYq9FK2PatMPhgAXK13oEHQ22uJJMfxerQeBeF8yPZST7QCbnQTYXHFpvtOAFDpC6 Mv8A== X-Forwarded-Encrypted: i=1; AJvYcCWCZ2dsAlCcPjfq4x/WCemU5/Npq84QgiBxmsnVzgfgDnVZzwlNlFYThUo2kOVYgh+n00Frbg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YweQFnSk++KvI5rv3o7q5Gn0q0AEKcCOt7Fo8KGXw2pPDmwlN5V XF7Tkw3nCwfusATfq080HvTew1v1gvFYot1DDuN1kXC+iaB1Jx9MK29mapuz4w== X-Gm-Gg: ASbGncvN3mzHNItjE+FNBV5IJeRcokzCcA25LJXjjwDyPvGe/Z5vxS/Zzz7+EU0Wlk6 LAI2Hv7lMtxPH5wZkYZHSVuh5zXRCob1Xodipii51XcL/n+oYmJaD3ZyOfZDz5t4pK+RLyGMbrK 7kEvdHfTCovJU2iUiGoDLzoQ9Vi6HtDoXnQoiwF0oTR26lktWIpUsOP8JIwZ0cqY7/Av9v/sn0E YNjxMAFT6lGPXQy2sk+ZL4JjXN2ellJTqXA3ISccr3G5kyJtdr18dgMtA96XhnEHXW11wdnVdIg nJxsOUA3BjFYPFrg8E6iaGJ+2ZjyzC2yJS4Y/ETu7UnO+86lgRb6tj986aylECGPOrnqE+jgmZn pq4u6kCkrDw== X-Google-Smtp-Source: AGHT+IHV422D1YUyoAkSSt+pKj1BAcNWf/qaTDdhXRA/ZP0BeRFpsY4elQj561OGQePYzdw7oBVheQ== X-Received: by 2002:a05:600c:6219:b0:456:43c:dcdc with SMTP id 5b1f17b1804b1-4563b8fcdcbmr96016015e9.33.1753108179114; Mon, 21 Jul 2025 07:29:39 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:502d:72af:3b4b:2e7b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4562bc17631sm134745255e9.0.2025.07.21.07.29.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Jul 2025 07:29:38 -0700 (PDT) From: Robert Pluim In-Reply-To: <87a557hq58.fsf@workbook> References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> <87frfhpe3z.fsf@gmail.com> <867c0t4ahz.fsf@gnu.org> <87bjq5p87x.fsf@gmail.com> <87a557hq58.fsf@workbook> Date: Mon, 21 Jul 2025 16:29:38 +0200 Message-ID: <87wm81ehwt.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Sun, 13 Jul 2025 15:00:51 -0400, Shawn Henson = said: Shawn> Just wanted to check in and ask if a decision has been made Shawn> regarding this bug. Not yet. >> So calling the sentinel in case 2 changes the behaviour, but that >> behaviour was already different, and then it would match what happens >> if the remote host exists but eg rejects the connection. Shawn> If calling the sentinel is the agreed upon solution, I may be wi= lling to Shawn> help if you think it would be a good first contribution. It=CA=BCs what I think the solution should be, I think we were kind of waiting for you to get back to us =F0=9F=98=80. Eli? Robert --=20 From unknown Sun Jul 27 03:20:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jul 2025 15:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: shawn@shenso.name, 78920@debbugs.gnu.org Received: via spool by 78920-submit@debbugs.gnu.org id=B78920.175311061122290 (code B ref 78920); Mon, 21 Jul 2025 15:11:02 +0000 Received: (at 78920) by debbugs.gnu.org; 21 Jul 2025 15:10:11 +0000 Received: from localhost ([127.0.0.1]:57852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uds9b-0005n2-5M for submit@debbugs.gnu.org; Mon, 21 Jul 2025 11:10:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48296) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uds9Z-0005hV-1E for 78920@debbugs.gnu.org; Mon, 21 Jul 2025 11:10:09 -0400 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 1uds9S-0003aK-Ua; Mon, 21 Jul 2025 11:10:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=OT+ExXLMzCOZaXQuS2/Fa+7VpvEXAXItCSirUoCPjgI=; b=rThbt7VKxxgXJtjq0eP6 L+L0o0epVltDYjbWky8zsDJW9Q5E+KnCyYFeUC0p04Hk0xuUxtozjMg6BanC0w10HKzFzRqG2suit JSDPvuoMUWXalyV+CdRs/oQRme8UJsFpxrv5LU8PA+luCro9knOZ5mtrmz3KVlGCf1SO3hrk7Copx 5NAZ+AtH9XqnPEtZVSg+hCTHxnCQghTcxQ+05NRCw882ZOzCkC1zM2Doormew0T95bl/KZ0Kz4IE5 Rl8/Fl5t9d9U5QaOrCInDMsunEX0OTDRQzOtdDLuQPRFNGMC45kLFGAQ6TE0sVWR4+VjvAZYRX/1n Dh2LvCMIhiUIXQ==; Date: Mon, 21 Jul 2025 18:10:00 +0300 Message-Id: <86jz41bmwn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wm81ehwt.fsf@gmail.com> (message from Robert Pluim on Mon, 21 Jul 2025 16:29:38 +0200) References: <5c05f134-cf72-4e1e-852e-f6e927a2d532@shenso.name> <86bjq75dwf.fsf@gnu.org> <419296ec-9ebd-4b33-8636-d5e616e6ec01@shenso.name> <8634bj55bx.fsf@gnu.org> <1fb9edab-7d92-4f0e-b259-c7e9b0d408c1@shenso.name> <875xgeqzq9.fsf@gmail.com> <87jz4udyzn.fsf@workbook> <87sejhpsi9.fsf@gmail.com> <86frfh4ciq.fsf@gnu.org> <87frfhpe3z.fsf@gmail.com> <867c0t4ahz.fsf@gnu.org> <87bjq5p87x.fsf@gmail.com> <87a557hq58.fsf@workbook> <87wm81ehwt.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: Eli Zaretskii , 78920@debbugs.gnu.org > Date: Mon, 21 Jul 2025 16:29:38 +0200 > > >>>>> On Sun, 13 Jul 2025 15:00:51 -0400, Shawn Henson said: > > Shawn> Just wanted to check in and ask if a decision has been made > Shawn> regarding this bug. > > Not yet. > > >> So calling the sentinel in case 2 changes the behaviour, but that > >> behaviour was already different, and then it would match what happens > >> if the remote host exists but eg rejects the connection. > > Shawn> If calling the sentinel is the agreed upon solution, I may be willing to > Shawn> help if you think it would be a good first contribution. > > Itʼs what I think the solution should be, I think we were kind of > waiting for you to get back to us 😀. Eli? I'd be happier if a couple more people who use network processes a lot would chime in and voice their opinions. There's also the question of what string to call the sentinel in this case.