Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

> (GNU) dd has support for progress bar and even if not enabled, one can get statistics by sending USR1 signal to it.

And the BSDs have siginfo, so at least most of the Free OSs are covered.

I forget which way it goes, but if you accidentally send an INFO to non-bsd dd (or maybe it is USR1 to bsd dd) it conveniently dies.

I believe the way it goes is that USR1 kills BSD dd.

The Linux kernel doesn't have SIGINFO. GNU dd uses SIGINFO on platforms that have it, or SIGUSR1 otherwise. The default action for SIGUSR1 is to kill the process. So it makes sense that on platforms that do have SIGINFO no one would bother to override that default SIGUSR1 behavior.

I think it's USR1 to bsd dd? SIGINFO doesn't exist on Linux from what I remember, but I think the default behavior for processes is to terminate when they receive a signal they don't catch, and I can't imagine many programs have explicit handlers for USR1, especially if SIGINFO is an option

The default handler for SIGINFO is a non-fatal process summary, like this (from FreeBSD):

    load: 0.15  cmd: sleep 52109 [nanslp] 0.27r 0.00u 0.00s 0% 2132k
    mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x1d1 kern_clock_nanosleep+0x1c1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8

SIGUSR1's default is to terminate the process, which makes it awkward to use as a SIGINFO alternative on platforms without it.

Reply on news.ycombinator.com