On Fri, 19 Dec 2025, Stephen Borrill wrote:
In case it's a clue, I found that the signal isn't entirely ignored, but it
takes 10 minutes to take effect:
builder10# copyparty
[snip]
^Z[1] + Suspended copyparty
builder10# bg
[1] copyparty &
builder10# date
Thu Dec 18 13:18:10 GMT 2025
builder10# kill -INT %1
builder10# fg
OPYTHAT
15:28:20.051 hsrv ok bye
15:28:20.051 tcpsrv ok bye
15:28:20.051 up2k writing snapshot
15:28:20.111 root nailed it
builder10#
That's 2hrs + 10 mins, right. Close to the 9001 secs. (2hr. 30 min.) default
timeout here:
https://github.com/9001/copyparty/blob/hovudstraum/copyparty/svchub.py#L1414_
so the signal might still be blocked.
Anyway, there are, at least, 2 things NetBSD is doing differently--compared to
the other Unixes I've tested (Free, OpenBSD & Linux):
1. The blocked signals shown for each thread in a ps(1) output just seems to be
a copy of the process's blocked signal mask. And _this_ is a _union_ of all
the LWPs blocked signal masks. This is very misleading.
2. If there is a sigwait() happening and also a signal handler for a signal
registered, then when it's time to deliver the signals, the sigwait()
(happening
in another thread) gets processed first, and the signal is never delivered
to the registered signal handler.
I'll have to talk to my standards guru about this---but, anyway these 2 might
actually not have anything to do with your copyparty issue. Investigation
is ongoing...
Note the bad pun so that if you type Ctrl-C it is meant to display ^COPYTHAT
Yeah :)
-RVP
