Hacker News Reader

Comment by saagarjha | Hacker News Reader

One of my favorite BSD features is SIGINFO, which is intended for applications to give some sort of information about what they’re currently doing. If you’re on macOS, I know some of the copying commands (such as dd) implement it, and a ^T in your terminal will tell you how far along it is.

View on HN

SIGINFO is awesome, I've no idea why the linux world refuses to copy its semantics.

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.

Huh, AFAIK on linux dd responds to SIGUSR1.

The trouble with SIGUSR1 is that the default action is terminate, so you can only send it to processes you know will take it well.

It's safe to send SIGINFO to processes that don't know about it; the default action is to ignore it. You can send it to an entire process group, and maybe some of them will answer it. But even if they don't, they won't just get killed for it.

This makes it so much more useful and discoverable, since you can almost always ^T with little risk. Usually you'll get at least a bit of information about how long the current command (more or less) has been running. If the running program happens to handle it, so much the better.

On Linux you can use progress¹ for many of these use cases. By default it scans for running processes that you might want to know about, but you can also ask it tell you about a PID with -p. It supports a -m[onitor] mode to report status until the command exits, and features some basic filtering options to ignore certain files.

You can also manually dig about in /proc/$pid/fd{,info}/ if you want something more fancy, like using gdbar² to display a graphical progress through files for a given process.

1. https://github.com/Xfennec/progress

2. https://github.com/robm/dzen

Its good but it suffers from the same slowdowns as htop when there are multiple operations happening as it crawls through /proc

Yeah, I'd recommend using the `-p $pid` option when you can. Not just because it doesn't need to scan all of /proc, like the -c[ommand] or default mode do, but also because it doesn't suddenly start listing other processes when you're in monitor mode.

That said, sometimes it is nice to see the other commands pop up in monitor mode. For example, when the rate suddenly drops in a command that you care about then the other output will often show the culprits for you to `kill -STOP`.

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...

https://stuff-things.net/2016/04/06/that-one-stupid-dd-trick...

This is absolutely fantastic; thank you for teaching me about this. Seems like the default output is

    load: {load%}  cmd: {cmd name} {PID} running {user time}u {system time}s

Being able to grab the PID from a currently running process -- in the same shell it's running in! -- is priceless on its own. The rest is icing on the cake.

Wow! I have been a Mac user since PPC was a thing, and I had no idea! Thank you!

Does cp support it (on a BSD)?

macOS's does.

Reply on news.ycombinator.com