Re: SIGINFO/SIGUSR1 and SIGUSR2

[Guy Harris <gharris () sonic net>]

On Mar 28, 2024, at 3:01 AM, Denis Ovsienko <denis () ovsienko info> wrote:

> There is a rather old pull request at [1], which was supposed to make
> use of the then-unused SIGUSR2, but whilst it was waiting, another pull
> request used the signal for another code path.
>
> There is a potential way to manage this kind of contention by
> naming the available actions and disassociating them from the available
> signals.  For example, let's call the existing SIGINFO/SIGUSR1 action
> "print_stats", the existing SIGUSR2 action -- "flush_savefile" and the
> action proposed in the pull request -- "rotate_savefile".  Perhaps an
> easy action would be "ignore" to do nothing instead of the default
> something.  Then these command-line options would allow to associate
> the signals with the actions:
>
> [--siginfo=<action>] (on platforms with SIGINFO only)

SIGUSR1 and SIGUSR2 are required by POSIX, so all UN*Xes should and, as far as I know, do support it.  They were 
introduced in System III (they may have been introduced inside AT&T prior to that, but the first release with SIGUSR1 
and SIGUSR2 that was made generally available was System III).  It looks as if they might first have appeared on the 
BSD side of the fence in 4.3BSD.

SIGINFO was a later addition, not in 4.3BSD.  It appears to have been in 4.3-Reno, along with SIGUSR1 and SIGUSR2:

        
https://man.freebsd.org/cgi/man.cgi?query=sigvec&apropos=0&sektion=0&manpath=4.3BSD+Reno&arch=default&format=html

so I suspect few, if any, UN*Xes have, or had, SIGINFO without also having SIGUSR1 and SIGUSR2.

As for "not UN*X but tries hard to look like it", Haiku has SIGUSR1 and SIGUSR2 but not SIGINFO.

SIGINFO is largely a BSDism, not adopted by Linux or System V Release 4 (which may have come out before *BSD* added it) 
or Haiku or AIX:

        https://www.ibm.com/docs/en/aix/7.3?topic=s-sigaction-sigvec-signal-subroutine

etc..

So I wouldn't worry abut platforms that only have SIGINFO; given that, on the platforms that offer it (BSDs, including 
CupertinoBSD), it's defined to mean "give me a status report" - unlike SIGUSR1 and SIGUSR2, which are explicitly 
defined *not* to have a standard meaning, leaving it up to the application to choose how to use it - I wouldn't bother 
with a --siginfo option.

Instead, we could have SIGUSR1 default to "print statistics" even on systems that *have* SIGINFO, continue to have 
SIGUSR2 default to "flush the savefile", and allow --sigusr1= and --sigusr2= to reassign either of those to 
"flush_savefile" or "rotate_savefile".  That means you can't, on platforms without SIGINFO, have "print_stats", 
"flush_savefile", and "rotate_savefile" signals, but that's because you don't have three signals to reassign.  On 
platforms *with* SIGINFO, you can use the other two for "flush_savefile" and "rotate_savefile".
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s