I was surprised with this comment in other question:
Sending dd the USR1 signal too soon after it has started (i.e. in a bash script, the line after you started it) will in fact terminate it
Can anybody explain why?
I was surprised with this comment in other question:
Sending dd the USR1 signal too soon after it has started (i.e. in a bash script, the line after you started it) will in fact terminate it
Can anybody explain why?
Each signal has a "default disposition" -- what a process does by default when it receives that signal. There's a table in the signal(7)
man page listing them:
Signal Value Action Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1 30,10,16 Term User-defined signal 1
SIGUSR2 31,12,17 Term User-defined signal 2
SIGUSR1
and SIGUSR2
both have the default action Term
-- the process is terminated. dd
registers a handler to intercept the signal and do something useful with it, but if you signal too quickly it hasn't had time to register that handler yet, so the default action happens instead
strace
output in a shell script…)
Commented
Apr 20, 2018 at 17:16
trap '' USR1
in the (sub)shell that is going to run dd
. Compare trap - USR1; dd if=/dev/zero of=/dev/null & kill -s USR1 "$!"; sleep 1; kill -s USR1 "$!"; sleep 1; kill "$!"
to trap '' USR1; dd if=/dev/zero of=/dev/null & kill -s USR1 "$!"; sleep 1; kill -s USR1 "$!"; sleep 1; kill "$!"
.
Commented
Jun 29, 2023 at 10:38
{ dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobs
to reproduce the effect you're describing.