Disable backtrace on SIGINT/SIGTERM signals by default

[david-macmahon]

When a Julia process is interrupted with SIGINT or terminated with SIGTERM, Julia outputs a fairly long stack backtrace to stderr. This backtrace may be of interest to Julia developers, but it is of little use to the end user. SIGINT and SIGTERM are commonly used to terminate a running process. Getting such a backtrace on stderr when doing so is not expected (what other program does this???) and can lead to pollution of log files. Not outputting these backtraces on SIGINT/SIGTERM by default would make Julia a better behaved program. If there are cases where these backtraces are useful, they could be optionally enabled by an environment variable and/or command line option.

[PhilipVinc]

I disagree.
While sometimes what you say is true, sometimes I want to know where Julia was stuck, especially with long running computations or Zygote compilations.
Looking at the stack trace is a cheap way to do that.

[david-macmahon]

I'm not advocating eliminating the backtraces altogether, just disabling them by default. One could always enable them for their long running process just in case it gets stuck after a while and they want a backtrace. I think sophisticated users who care about backtraces are probably savvy enough to attach a debugger to the process to get backtrace information and more, but I understand that's not always as convenient.

Instead of debating the pros and cons of the default setting, maybe we can agree that it would be nice to provide an option to change the behavior from the default. As it is now (1.6.1) it seems impossible to disable these backtraces.

[vtjnash]

Though well-behaved programs should also generally not be using SIGINT, and especially not using SIGTERM, to gracefully terminate a running process. Those are reserved for abruptly and abnormally (respectively) requesting process termination. Though @PhilipVinc, you can also send SIGUSR1/SIGINFO/^T to the process to dump the current stack, without interrupting it.

[david-macmahon]

The primary purpose of SIGTERM is to ask a program to terminate. The GNU C Library manual says: "It is the normal way to politely ask a program to terminate."

https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html

One way to avoid the backtraces currently is to use SIGKILL, but that's getting a bit drastic.

[stevengj]

See also #40138.

[StefanKarpinski]

I do think that this might not be necessary if stack traces were shorter in the first place.

[david-macmahon]

I think there are two different use cases here:

1. An interactive REPL session that is terminated via SIGINT/SIGTERM
2. A daemonized Julia process (possibly logging stdout/stderr to a log file) that is terminated via SIGINT/SIGTERM

I think that killing an interactive REPL session via SIGINT/SIGTERM is rare/not normal. Spamming backtraces to the terminal in that case is probably going to make some users happy because they might find clues about what went wrong. Most other users won't care about them because it's a rare event and they likely have other things to worry about when this happens.

OTOH, SIGTERM is a normal way of terminating a daemonized process. Backtraces spammed in this case are not going to have any clues for what went wrong because nothing went wrong -- the process just terminated normally. These backtraces have no positive value whatsoever. They arguably have negative value because they can end up polluting log files thereby making it harder to read the log files to find actual clues to actual problems. It is abnormal for a demonized process terminating in that manner to spam backtraces on exit. How many other programs do that???