libjsig deprecation warning, lenience for signal(SIGPIPE, SIG_IGN)?

[Mikael Sterner]

On Mon, Apr 14, 2025, at 05:20, David Holmes wrote:
> On 11/04/2025 2:59 pm, Mikael Sterner wrote:
>> However, tracing what triggered our warnings, I wonder if you
>> think it could make sense to be lenient about calls to deprecated
>> signal() method that just want to ignore a signal with SIG_IGN,
>> in particular SIGPIPE?
>
> I have been trying to think of a rationale that would justify this 
> leniency for this case, but I'm struggling to formulate one. The warning 
> is about the use of the API not about how the API is used (i.e. the 
> given signal and the way it is to be handled does not come into it).
>
> Would it help in your case if there was a way to disable the warning via 
> a command-line flag? This has been requested in the past but we haven't 
> needed to go down that path due to other adjustments (and sometimes it 
> won't help as control of the command-line is problematic).

It would be awesome if OpenJDK had a policy of always allowing
application developers to disable deprecation warnings on the 
command line.* But in this case I guess it also depends if you
ever intend to make programs calling signal() crash when libjsig
is loaded, or if it will stay a warning forever?

> Just to get a clearer picture here, the fact you are using libjsig 
> indicates there are other signals that are actually handled and which 
> you need to be chained - is that correct?

Yes, we need to handle signals raised by other third-party
libraries, but there we have more control over which methods
to use.

Possibly there are also other third-party libraries calling 
signal() with the intent of actually catching signals, that I 
haven't yet noticed (since the warning is only given for the
first call). 

I think that some native libraries we use, we basically have to
pamper to believe they are running in a single-threaded program.

On a similar topic, I was happy to see JDK-8346381 to fix the
signal chaining on modern macOS versions. Just to let you know
that these facilities are being used in the wild.

>> Or would it be better to report such calls as deficiencies in
>> these libraries, with the libjsig warnings as evidence?
>
> The "evidence" would be the specification for signal on Linux:
>
> https://man7.org/linux/man-pages/man2/signal.2.html
>
> WARNING: the behavior of signal() varies across UNIX versions, and
>           has also varied historically across different versions of Linux.
>           Avoid its use: use sigaction(2) instead.

Thanks, that would be a good reference to use.

Yours,
Mikael Sterner

* Looking at you, JEP 411: https://mail.openjdk.org/pipermail/security-dev/2021-May/026200.html