SIGPIPE error

[malc_b]

Hi,

I'm using HiPi.pm and I get the occasional error in the log like this:

Code Auswählen Erweitern


Interrupt SIGPIPE at /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1/HiPi.pm line 79, <GEN31> line 839.

2020.02.16 13:12:57 1: txt:97:13:10:31:139:8:0:0:0:0:0:0:3:13:10,len:15,off:0
2020.02.16 13:12:57 1: stacktrace:
2020.02.16 13:12:57 1:     main::TcpServer_WriteBlocking       called by ./FHEM/01_FHEMWEB.pm (2131)
2020.02.16 13:12:57 1:     main::FW_outputChunk                called by ./FHEM/01_FHEMWEB.pm (2191)
2020.02.16 13:12:57 1:     main::FW_returnFileAsStream         called by ./FHEM/01_FHEMWEB.pm (780)
2020.02.16 13:12:57 1:     main::FW_serveSpecial               called by ./FHEM/01_FHEMWEB.pm (861)
2020.02.16 13:12:57 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (583)
2020.02.16 13:12:57 1:     main::FW_Read                       called by fhem.pl (3763)
2020.02.16 13:12:57 1:     main::CallFn                        called by fhem.pl (755)
2020.02.16 13:12:58 1:

There is nothing in the stack trace about HiPi so I wonder if this is HiPi handling a SIGPIPE meant for FHEMWEB.pm (is that possible?).  The occurrence of the error seems random and I haven't found a way to reproduce it.

Can someone explain what it is telling me too .
And suggest what to do about it.

Thanks

[rudolfkoenig]

HiPi.pm overwrites the signal-handlers defined by FHEM.pl, which results in side effects like this.
I cannot explain yet why/how the FHEM stacktrace() is called in this context: probably die() is playing some role in it, but the $SIG{__DIE__} handler in FHEM ist not activeted.

[malc_b]

HiPi.pm overwrites the signal-handlers defined by FHEM.pl, which results in side effects like this.
I cannot explain yet why/how the FHEM stacktrace() is called in this context: probably die() is playing some role in it, but the $SIG{__DIE__} handler in FHEM ist not activeted.

Thanks.  Bu the $SIG{__DIE__} handler in fhem is commented out.  Also fhem has $SIG{PIPE} = 'IGNORE';.  The author of HiPi suggests following use HiPi.... with $SIG{PIPE} = 'IGNORE'; to restore fhem default behaviour which seems a good suggestion.  Googling finds that most advice is to ignore pipe errors and handle the return errors instead.  Presumably the tcp stack is doing that and just retrying.