https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35111
--- Comment #15 from David Cook <[email protected]> --- As you can see, the SIGPIPE happens before a child process is forked. And since we're at line 137 we know that we've received a message from RabbitMQ. Since the DB job is stuck in "New" and no worker can pick up the message from RabbitMQ after this, we know that the message has been ACKed via $conn->ack( { frame => $frame } ); So it's not the connection with RabbitMQ. And since the stacktrace shows the SIGPIPE when the database connection is checked to see if it's connected, I think it's pretty clear that it's the SIGPIPE from the broken database connection causing the problem. The restart of the database causing a consistently reproducible SIGPIPE also shows it's the database connection in the parent process that is producing the SIGPIPE. In https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35111#c7 I do some software version comparisons which demonstrate that it is likely related to the C client libraries. I will admit that I don't have 100% proof that it's the C client libraries having different behaviours, but I think it's a pretty good hypothesis. -- Another thing to keep in mind is that daemons typically ignore SIGPIPE. This is why we have no issues with the Starman daemon for instance. It's a good practice in general, so there's no harm in adding it into this daemon. (We may want to look at other daemons at some point as well.) -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
