Autor Thema: SIGPIPE error  (Gelesen 325 mal)

Offline malc_b

  • Developer
  • Full Member
  • ****
  • Beiträge: 108
SIGPIPE error
« am: 16 Februar 2020, 18:40:01 »
Hi,

I'm using HiPi.pm 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


Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21952
Antw:SIGPIPE error
« Antwort #1 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.

Offline malc_b

  • Developer
  • Full Member
  • ****
  • Beiträge: 108
Antw:SIGPIPE error
« Antwort #2 am: 20 Februar 2020, 09:45:18 »
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.