5 ms·

Huh, AFAIK on linux dd responds to SIGUSR1.

voxadam 7y ago
https://stuff-things.net/2016/04/06/that-one-stupid-dd-trick-and-the-ballad-of-siginfo/ https://stuff-things.net/2016/04/06/that-one-stupid-dd-trick...
naniwaduni 7y ago
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.
saagarjha 7y ago
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/dd.c;h=e92fe007c73ae3e7347f287f8f922a0d56f93d6a;hb=HEAD#l64 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...
JNRowe 7y ago
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 https://github.com/Xfennec/progress 2. https://github.com/robm/dzen https://github.com/robm/dzen
- tetris11 7y ago
  Its good but it suffers from the same slowdowns as htop when there are multiple operations happening as it crawls through /proc
  - JNRowe 7y ago
    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://stuff-things.net/2016/04/06/that-one-stupid-dd-trick-and-the-ballad-of-siginfo/ https://stuff-things.net/2016/04/06/that-one-stupid-dd-trick...

naniwaduni 7y ago

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.

saagarjha 7y ago

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/dd.c;h=e92fe007c73ae3e7347f287f8f922a0d56f93d6a;hb=HEAD#l64 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...

JNRowe 7y ago

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 https://github.com/Xfennec/progress 2. https://github.com/robm/dzen https://github.com/robm/dzen

tetris11 7y ago
Its good but it suffers from the same slowdowns as htop when there are multiple operations happening as it crawls through /proc
- JNRowe 7y ago
  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`.