Date: Wed, 10 Jun 2026 20:56:18 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 292322] Hastd failing to g_attach device on FreeBSD 15.0 Message-ID: <bug-292322-227-qkKLjwDebU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-292322-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292322 Martin Vidovic <xtronom@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xtronom@gmail.com --- Comment #2 from Martin Vidovic <xtronom@gmail.com> --- I've hit this exact problem when setting up HAST on FreeBSD 15.0 and decided to investigate, here is the summary: The timeout on the secondary node ("Unable to receive header") was traced to the parent/worker connection migration path in hastd (on primary) rather than the replication protocol itself. The connection migration code transfers a protocol name and a connected socket descriptor over a local AF_UNIX socketpair. The protocol name is sent using send(2), while the descriptor is sent separately using sendmsg(2) with SCM_RIGHTS. The receive side calls recv(2) with a buffer sized for the maximum protocol name length and uses MSG_WAITALL. On FreeBSD 15.0 this causes the receiver to wait indefinitely for the full buffer size rather than returning after receiving the protocol name. Because of this the primary never sends the HAST header and the resource doesn't appear in /dev/hast/. A review has been submitted with a patch that sends the protocol name and descriptor together using a single sendmsg()/recvmsg() exchange. With the patch applied, the primary successfully creates /dev/hast/, the secondary receives the HAST protocol header, and synchronization completes successfully. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-292322-227-qkKLjwDebU>