bug-ddrescue
[Top][All Lists]
Advanced

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

Re: [Bug-ddrescue] Feature request: email notifications about the progre


From: Ketil Froyn
Subject: Re: [Bug-ddrescue] Feature request: email notifications about the progress
Date: Fri, 1 Jun 2018 22:02:52 +0200

On Jun 1, 2018 17:09, "Antonio Diaz Diaz" <address@hidden> wrote:

Hi Paul,


Paul Daniels wrote:
>      I've got a mailfeeder tool that I wrote for testing a long time in
> the past, uses standard sockets type stuff in linux in plain C, BSD
> licenced and no external libs required.

Thank you.

I do not plan to implement in ddrescue any mail client code. Using the
unix toolbox philosophy I was thinking about someting like make ddrescue
execute

   system( "echo <message> | mailx -s <subject> address@hidden" );

and just provide the means to specify the email address and a pointer to
the configuration documentation of mailx (or whatever email client
used). BTW, the mailx command in my machine does not seem able to send
emails to the outside world.



ST wrote:
> PS: such hooks could be used also for other stuff - like backing up the
> so far rescued image to an sftp-server (just in case)...

Working commands suitable for something like the system call above are
welcome. ;-)


I think it would be useful to be able to supply generic commands to
ddrescue for various trigger conditions. It'd be nice to send a
notification on progress, but further processing might also be launched, or
backing up as outlined. Also, if ddrescue could launch different commands
on different conditions, this could open up for new possibilities, like
triggering custom hardware to power cycle a drive, for example.

I think it might make sense to pass arguments via environment variables.
ddrescue could read some suitable environment variables to determine if the
user has specified a script, something like:

$ export DDRESCUE_PROGRESS=/path/to/progress_notification_script
$ ddrescue /dev/sdb output mapfile

Also, ddrescue could in turn pass args to the subprocess via the
environment.

if (getenv( "DDRESCUE_PROGRESS" )) {
    char *noargs[] = { NULL };
    char *environ[] =
{ "DDRESCUE_INPUT=/dev/sdb", "DDRESCUE_OUTPUT=output",
"DDRESCUE_MAPFILE=mapfile", "DDRESCUE_PROGRESS=progressinfo",
NULL};

    execve( getenv("DDRESCUE_PROGRESS"), noargs, environ );
}

A possible drawback, of course, is that spawned processes can crash and
hang, so they should be watched carefully. I'd think the coreutils' timeout
commands is fairly good at this.

https://github.com/coreutils/coreutils/blob/master/src/timeout.c

Regards, Ketil


reply via email to

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