Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Not so much an answer to your question, but try this one-liner: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobs to reproduce the effect you're describing. – jippie May 13 '12 at 22:26
up vote 20 down vote accepted

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

share|improve this answer
I wish I could upvote twice for being made aware of this obscurity. Seeing processes die randomly after removing an explicit signal handler was disconcerting. – DeaconDesperado Mar 9 at 19:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.