I'm not familiar with what you're doing, so this may be a stupid question.
Why not use the SIG_DFL handler, then just catch the resultant IOError
exception and retry?
On Wed, Aug 2, 2017 at 8:53 PM, <vk3...@gmail.com> wrote:
> This relates to the latest update of my HP1000 (and clone) driver where
> I've added in code to read historical records from the weather station.
> Configuration: weeWx 3.6.2 running on a Raspberry Pi 3 with the latest
> To read the historical records, the driver makes a number of network
> requests to the weather station and generates a number of REC records back
> to weeWx - I can see each of these records being reported in the system log
> file. However, seemingly at random, I'm getting "Error 32 Broken Pip"
> errors from the network accesses. The way I was handling all errors
> originally was to simply let weeWx handle them (which in this case meant it
> went on to the normal LOOP packet generation process) but this meant that I
> was missing historical records.
> Because of the way my code works, it only tries to catch up from the last
> "good" record and does not try to go back to fill in previous gaps.
> Therefore this resulted in 'gaps beng created as soon as the next archive
> record was written by weeWx.
> Looking at the internet, it seems that this is a "known error" (
> errno-32-broken-pipe-python) with the suggested work around being to add
> from signal import signal, SIGPIPE, SIG_DFL
> This seems to have the overall desired effect but by causing weeWx to
> 'crash' when the broken pipe error occurs and 'systemctl' then restarts it
> and it picks up form where it left off. However this is hardly ideal!!!! I
> don't like work-arounds like this are actually ignore the root cause.
> In the system log I've noticed that weeWx tries to write a lot of messages
> to WOW (the only external service I've activated) - one for each REC I
> provide - and often there are error messages such as:
> restx: WOW: Failed to publish record 2017-08-01 19:36:07 AEST
> (1501580167): Failed upload after 3 tries
> The original driver worked well but did not access the weather station
> often and with large packets.
> I'm just wondering if others have some across broken pipes and/or have any
> idea what is the underlying cause?