bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] Retrying/killing


From: Elliot Chandler
Subject: Re: [Bug-wget] Retrying/killing
Date: Tue, 2 Oct 2018 13:12:58 -0400

The new --retry-on-host-error option might prevent the need for
complicated shell retry logic (it was added for the exact problem of a
flaky network connection). That option is not yet in a tagged release,
but it's been merged.

Hope this helps!

On Tue, Oct 2, 2018 at 11:42 AM Paul Wagner <address@hidden> wrote:
>
> Dear wgetters,
>
> I'm trying to grab some webradio programmes with wget and have
> encountered two difficulties:
>
> * First, my internet connection sometimes breaks, and I would like wget
> to retry as long as I don't kill it.  I tried wget --tries=inf
> --retry-connrefused, but that does not retry e.g. when the interface
> goes down (this is how I tested my script).  Am I missing something
> here?
>
> * In order to have my script retry, I ended up with something like
>
> function job() {
>      i=0
>      while true
>      do
>          i=$((i+1))
>          wget -a "$name.log" -O "$name-$i.mp3" "$url"
>      done &
>      sleep $length
>      kill $!
> }
>
> while true
> do
>      t=$(date '+%M %H')
>      while read startmin starthour length url name
>      do
>          [[ $t == $startmin' '$starthour ]] && job &
>      done < conf-file
>      sleep 60
> done
>
> Interestingly, the 'kill $!' kills the loop, but wget is not killed, but
> lives on with init as parent process.  Not really understanding what is
> going on here I can only guess this 'detaching' of the wget-process
> happens because it's ignoring SIGHUP?  The only solution I could come up
> with is using 'ps' to find the PID of the wget that has the
> loop-subshell as PPID, then killing the loop, and then killing wget
> separately, but this is so ugly that I can't imagine that there is no
> neat solution.
>
> (Apologies if this isn't the appropriate place for asking this, as it
> might actually be a bash-question.  Any other suggestions or remarks
> highly welcome, too.)
>
> Kindest regards,
>
> Paul
>
>



reply via email to

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