Hi,
I'm using HiPi.pm (https://raspberry.znix.com/) and I get the occasional error in the log like this:
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
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.
Zitat von: rudolfkoenig am 16 Februar 2020, 20:26:29
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.