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

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

Reply via email to