IRC channel logs

<damo22>youpi: i think there is an error in master gnumach tip commit, you added an extra row for BOOT_CS but that means the BOOT_DS is a ACC_CODE_R

<damo22>i am mailing in a patchset with the first commit fixing this

<damo22>i find gdb useless without (gdb) set output-radix 16

<damo22>chasing a strange bug cr2 = 0x4000000036

<damo22>cpu_launch_first_thread(THREAD_NULL) ??

<damo22>how does that work?

<rrq>I have a question about unix socket protocol. it seems client ends up hanging indefinitely if the server listens but doesn't accept ... or is there a timeout?

<youpi>I would see that as the expected behavior

<rrq>that it hangs indefinitely?

<youpi>until the server accepts, yes

<youpi>from the point of view of tcp, the connection is already accepted

<youpi>so the client has no way to know whether the server has accepted or not

<youpi>on unix sockets I would see that as expected behavior too

<rrq>yes makes sense. though it was a difference wrt linux we observed with socat ,, for unix-connect:

<rrq>hurd hangs whereas linux gets a connection error

<rrq>thanks

<youpi>a connexion error ?

<youpi>after some delay?

<youpi>a connexion error should only appear if the listen queue is already full

<youpi>if hurd's pflocal doesn't refuse new clients when the listen queue is full, that's a bug that should be fixed

<rrq>yes, I'm not sure exactly where/when/how the linux connection attempt fails. It just came up during porting a Devuan package to hurd; the test suite included a test that incidentally relied on that failure

<rrq>it should have had a timeout already.

<youpi>we'd need an actual reduced example to be able to progress on this

<rrq>I asked only as I wanted this clarity of that difference. the test command was "socat -s stdout unix-listen:$pathname" ... where the server side was listening but not accepting

<rrq>(that command constitute a "trigger" on the socket, and in this test it was expected to fail)

<rrq>a common ground is achieved by using -T0 instead of -s

<rrq>btw a second issue is the use of so_reuseport .. where hurd differs from linux

<rrq>I ventured the guess that hurd is closer related to freebsd and perhaps it should the use so_reuseport_lb (for hurd; will need portability ifdef)

<rrq>sorry, correction: the test command waas "unix-connect:"

<azert>rrq: a clear test with both the server as well as the client parts would be useful

<rrq>right. the package is "sasa" (stand-alone socket activation) with source at https://git.devuan.org/leepen/standalone-socket-activate ... and this was in its test suite. I'll try to curate it a bit to focus in this issue for hurd.

<rrq>I may note that Devuan have set up the Jenkins build pipeline to allow building on hurd (using a hurd-amd64 VM) and are now slowly "porting" the Devuan forked packages.

<rrq>well, it's not really an issue I guess since hurd is basically more well-behaved than linux; so it's more a matter of dissecting/verifying the difference.

IRC channel logs

2026-01-07.log