tcpdump mailing list archives
Re: SIGINFO/SIGUSR1 and SIGUSR2
From: Denis Ovsienko <denis () ovsienko info>
Date: Thu, 28 Mar 2024 21:19:44 +0000
On Thu, 28 Mar 2024 12:44:29 -0700 Guy Harris <gharris () sonic net> wrote:
[--siginfo=<action>] (on platforms with SIGINFO only)
[...]
so I suspect few, if any, UN*Xes have, or had, SIGINFO without also having SIGUSR1 and SIGUSR2.
Thank you for providing the historic background. The above was supposed to mean "only on platforms that have SIGINFO (and any other signals)".
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..
Yes, AIX and Haiku sometimes make portability issues manifest.
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".
Changing the compiled-in defaults would be one thing, and given how long ago the current behaviour was implemented, it would be best to think twice before changing it. There are users with learned keystrokes and scripts that work, let's keep it this way when possible. Allowing to override the defaults at run time would be another thing, which would not depend on the compiled-in defaults. Besides the obvious "I need to use this action for this one tcpdump process somehow and it does not have a default signal" use case, it would also make it possible, for instance, to run one group of tcpdump processes with "--sigusr1=ignore --sigusr2=rotate_savefile" and another with "--sigusr1=rotate_savefile --sigusr2=ignore" and then to use killall remembering only the correct signal to use for the group, but not which group comprises which PIDs. This feature would only need to detect the set of user-configurable signals at build time, to show the set and its default actions on request, and to allow changing individual actions, then the users could make sense of that as each use case requires. -- Denis Ovsienko _______________________________________________ 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
Current thread:
- SIGINFO/SIGUSR1 and SIGUSR2 Denis Ovsienko (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Guy Harris (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Denis Ovsienko (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Guy Harris (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Denis Ovsienko (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Denis Ovsienko (Mar 28)
- Re: SIGINFO/SIGUSR1 and SIGUSR2 Guy Harris (Mar 28)