On Thu, 28 Mar 2024 15:28:00 -0700 Guy Harris <ghar...@sonic.net> wrote:
> On Mar 28, 2024, at 2:19 PM, Denis Ovsienko <de...@ovsienko.info> > 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