dd dies on SIGUSR1

Chris Rees utisoft at gmail.com
Wed Mar 23 21:05:26 UTC 2011

On 23 March 2011 02:18, J. Hellenthal <jhell at dataix.net> wrote:
> No offense but there has been plenty of reasoning here just given in your
> very own message at the top. I can probably count the number of times that I
> have had to actually had to use -USR1 & -USR2 on two hands.

So... why do you care what it does by default?

Basically, people who know what it does by default don't use it.

People who do use it can get hurt by the process death that occurs, or
at least a little annoyed.

> Assuming -USR[N] will get you -INFO does not mean the utilities you were
> using were incorrect and needed to be changed. It means you need to change
> your aspect of the portability of your syntax. Some systems go to far to
> keep the end-user from shooting them self in the foot and this would be one
> of those cases.

No, this is not akin to alias rm rm -i.

We are not talking about changing the behaviour of a commonly-used facility.

We are talking about a design decision taken decades ago, which quite
possibly was a mistake.

Again, how many people rely on USR1 to terminate a process?

> If a program receives a signal it should do *something* if it has nothing to
> do then it should *terminate*. The author of said software here gave it
> nothing else to do, therefore it terminates...

Because of a poor design decision-- that we easily fix with no breakage.

This is NOT 'preventing foot-shooting', this is making it less painful
to make a mistake for no disadvantage.

It will not be written into scripts to make them non-portable, or any
other horrible consequences that usually occur with anti-foot-shooting
measures. It is a benign change!

If no-one will agree with me on changing USR[12] then at least someone
please either commit the original patch in the PR [1], or close it!


***One last time, what possible disadvantage is there to changing
default of USR signals to ignore?***

Now I'll shut up and live with whatever is decided. Thanks for reading.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/155034

More information about the freebsd-standards mailing list