[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dd SIGUSR1 race

From: Federico Simoncelli
Subject: Re: dd SIGUSR1 race
Date: Thu, 25 Sep 2014 08:26:24 -0400 (EDT)

----- Original Message -----
> From: "Pádraig Brady" <address@hidden>
> To: "Coreutils" <address@hidden>
> Cc: "Federico Simoncelli" <address@hidden>
> Sent: Monday, September 22, 2014 5:25:58 PM
> Subject: dd SIGUSR1 race
> There is a race with dd setting up the signal handler for SIGUSR1,
> and some async process sending it.  If dd loses the race it's killed.
> This was pointed out to me by Federico (CC'd). The race was addressed,
> but only narrowed with:
> I was wondering about making things more general by allowing
> the parent process to set SIGUSR1 to SIGIGN, and dd would still
> setup the signal handler in this case.  This isn't too much of
> a stretch I think as it would only possibly result in unwanted
> output to stderr (and dd is already quite noisy to stderr by default),
> rather than unwanted process termination.

If you think in terms of a monitoring process, it would have to:

 ignore_sigur1() // sadly I don't think you can move this inside fork

 if !fork()  {
     exec("dd", ...)

 // how do we detect that exec got executed and we can stop ignoring
 // sigusr1? ...also we'd have a short period of time where the driving
 // app would be ignoring sigusr1. Any suggestion on how to fix this are
 // welcome.

 while true {

     // we could be blocked here forever if the sigusr1 was received by
     // the forked process before exec or if dd didn't setup the sigusr1
     // handler yet. We could use a timeout but still, it doesn't seems
     // a clean solution.

     if dd_is_dead()

     update_dd_progress() // consume dd output to update the progress

> Though doing the above would still need existing apps to change
> (to ignore SIGUSR1), so instead it might be better to just support
> a simpler mechanism through something like a "status=progress" option,
> which would avoid the general issues and awkwardness of signals as mentioned
> here:
> I'm leaning towards the latter option here.

+1, it seems much simpler, cleaner and has less implications.

Question is:

- should dd report bytes read/written or percentage? (I prefer bytes)

- how often should it be reported/updated? (every x seconds or x byte
  transferred? configurable?)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]