While named somewhat poorly for what it is sometimes used for SIGQUIT can be used for this. Ping uses it for statistics reporting in the middle of pinging. You can use Ctrl+\ in the terminal to send it. E.g.

    $ ping google.com
    PING google.com (172.217.5.110) 56(84) bytes of data.
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=1 ttl=54 time=4.04 ms
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=2 ttl=54 time=4.04 ms
    2/2 packets, 0% loss, min/avg/ewma/max = 4.037/4.039/4.037/4.042 ms
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=3 ttl=54 time=4.16 ms
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=4 ttl=54 time=4.06 ms
    4/4 packets, 0% loss, min/avg/ewma/max = 4.037/4.076/4.054/4.164 ms
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=5 ttl=54 time=4.19 ms
    64 bytes from sfo03s07-in-f110.1e100.net (172.217.5.110): icmp_seq=6 ttl=54 time=4.20 ms
    ^C
    --- google.com ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 11ms
    rtt min/avg/max/mdev = 4.037/4.114/4.195/0.068 ms

I was thinking it was SIGINFO, but this reminded me of the SIGUSR1 trick to get the current status of a running dd process-

  $ dd if=/dev/zero of=/dev/null& pid=$!
  $ kill -USR1 $pid; sleep 1; kill $pid
  
  18335302+0 records in 18335302+0 records out 9387674624 bytes (9.4 GB) copied,  34.6279  seconds, 271 MB/s

That's interesting. I always wonder how people monitored the progress of dd before it added the status option.

Now you can use the status option to get a realtime update of the progress.

dd if=/dev/urandom of=/dev/null status=progress

It is siginfo on BSDs, sigusr1 is the fallback.

There have been attempts to do so over the years. https://lkml.org/lkml/2019/6/5/174 was one. I haven't looked to see what became of them.

Signal numbers are a non-renewable resource, perhaps they think it'll cut into their valuable reserves ;)

I have used SIGUSR1 and SIGUSR2 for this purpose at work.

The problem of SIGUSR is it has no defined semantics and defaults to terminating the application, so you can't just throw SIGUSRs at random process, you need to know somehow that the process does something useful. Furthermore I don't think sigusrs have a control code.

SIGINFO is ignored by default, and pretty clearly an info-dump trigger, so you can throw ^T at any random utility you're running, worst case scenario is you'll just get a time-type dump.