[Feature suggestion] Handling SIGINFO in the CLI

Feature
#1

On many bsd OSes SIGINFO signal is bound to Control+T, and it’s hyper useful for asking long running silent processes about their current status.

Would be great is duplicacy handled SIGINFO.

For example, when running a very long prune after dumping list of snapshots to be deletes duplicacy sits silent for days – pressing Command+T dumps default information that is not very useful.

sh-3.2# duplicacy prune -r 1531-1721
Repository set to /Users
Storage set to gcd://Duplicacy
Deleting snapshot obsidian-users at revision 1531
...
Deleting snapshot obsidian-users at revision 1721

# Pressing Command+T invokes default handler 
# that prints system load and process information: 
load: 2.78  cmd: duplicacy_osx_x6 6327 waiting 56.99u 7.57s

Instead, duplicacy could dump what’s it actually doing at this point.

Rclone handles this signal, and it’s very useful.

1 Like
#2

Good idea. I’ll look into this.

P.S. I’m wondering if it is possible to start an http profiler for debugging in this Command+T handler.

#3

That would be very unexpected behavior for users that are used to a well established behaviors and intent of the SIGINFO

SIGINFO

The SIGINFO signal is sent to a process when a status (info) request is received from the controlling terminal.

But adding handler for another custom signal (SIGUSR1 or SIGURS2) — why not? It would he actually super helpful for instances when reproducing a bug is hard.