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

[David Holmes]

On 14/04/2025 5:06 pm, Mikael Sterner wrote:
> 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.* 

The problem there is that we don't have a common mechanism for such 
warnings. Hotspot, for example, uses Unified Logging, so you do have 
control. JDK/Java-level deprecation warnings are a whole other matter - 
as you know. Then we have libjsig which is a standalone set of C 
functions that just use fprintf for the warning - so any mechanism to 
disable it is made complicated by the need to somehow communicate a 
command-line request to the jsig code. It can be done but introduces 
additional coupling.

> 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?

At this stage it is likely to stay a warning for a very long time. We 
were expecting the OS (or glibc I guess) to eventually remove these 
functions, but that doesn't seem to be happening any time soon. Though 
the compilers do flag them as deprecated (if you have that warning enabled).

If we were to remove support for them it would "simply" mean that we 
would not intercept them and thus signal chaining would be broken. What 
would happen then depends on the signal of course. Though potentially we 
could convert signal() calls to sigaction() if we needed to keep old 
code working.


>> 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.

Ouch.

> 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.

That is good information to have. Occasionally someone will ask "do we 
still need all this old signal stuff?".

I will keep thinking about this, and see if anyone else has anything to 
contribute.

Cheers,
David

> 
>>> 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