[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2
On Thu, 28 Mar 2024 15:28:00 -0700 Guy Harris wrote: > On Mar 28, 2024, at 2:19 PM, Denis Ovsienko > wrote: > > > Yes, AIX and Haiku sometimes make portability issues manifest. > > And, in this case, Solaris doesn't have SIGINFO, either; SunOS > 0.x-4.x didn't have it, as BSD hadn't picked it up, and they didn't > pass it along to be put into SVR4, so it's not in the SVR4-based > SunOS 5.x. > > As noted, neither does Linux. > > I.e., at this point, if it's not named "somethingBSD" or "Mac OS X/OS > X/macOS", it doesn't have SIGINFO. illumos declares it as number 41 and implements it normally. SIGINFO causes: tcpdump: 54 packets captured, 924 packets received by filter, 0 packets dropped by kernel (tcpdump continues to run) SIGUSR1 causes: User Signal 1 (tcpdump exits) > > 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. > > The only change I'm suggesting to the compiled-in defaults is to > change the default for SIGUSR1 from the current default of > "print_stats if the system doesn't have SIGINFO, kill the process if > it doesn't" to "print_stats regardless of whether the system has > SIGINFO"; neither the default for SIGINFO (print_status if the system > has it) nor the default for SIGUSR2 (flush_savefile) would be changed. > > I don't see a way in which any remotely reasonable learned keystroke > or script would depend on SIGUSR1 killing the process on *BSD/macOS, > so I don't see an issue with SIGINFO *and* SIGUSR1 both causing stats > to be printed. Alright, this time it makes sense. Should be reasonably backward compatible. > > Allowing to override the defaults at run time > > Which is what I was talking about there. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2
On Mar 28, 2024, at 2:19 PM, Denis Ovsienko wrote: > Yes, AIX and Haiku sometimes make portability issues manifest. And, in this case, Solaris doesn't have SIGINFO, either; SunOS 0.x-4.x didn't have it, as BSD hadn't picked it up, and they didn't pass it along to be put into SVR4, so it's not in the SVR4-based SunOS 5.x. As noted, neither does Linux. I.e., at this point, if it's not named "somethingBSD" or "Mac OS X/OS X/macOS", it doesn't have SIGINFO. > 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. The only change I'm suggesting to the compiled-in defaults is to change the default for SIGUSR1 from the current default of "print_stats if the system doesn't have SIGINFO, kill the process if it doesn't" to "print_stats regardless of whether the system has SIGINFO"; neither the default for SIGINFO (print_status if the system has it) nor the default for SIGUSR2 (flush_savefile) would be changed. I don't see a way in which any remotely reasonable learned keystroke or script would depend on SIGUSR1 killing the process on *BSD/macOS, so I don't see an issue with SIGINFO *and* SIGUSR1 both causing stats to be printed. > Allowing to override the defaults at run time Which is what I was talking about there. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2
On Thu, 28 Mar 2024 12:44:29 -0700 Guy Harris wrote: > > [--siginfo=] (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-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2
On Mar 28, 2024, at 3:01 AM, Denis Ovsienko 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=] (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 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=0=0=4.3BSD+Reno=default=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-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] SIGINFO/SIGUSR1 and SIGUSR2
Hello all. 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=] (on platforms with SIGINFO only) [--sigusr1=] [--sigusr2=] In this case the following defaults would provide backward compatibility: (on platforms with SIGINFO) --siginfo=print_stats --sigusr2=flush_savefile (on platforms without SIGINFO) --sigusr1=print_stats --sigusr2=flush_savefile Then, if tcpdump prints the defaults and the available actions on --help, it should be straightforward for the user to change the response as necessary, including the action from the pull request: --sigusr2=rotate_savefile 1: https://github.com/the-tcpdump-group/tcpdump/pull/570 -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
