https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35111
--- Comment #10 from Marcel de Rooy <[email protected]> --- I am still wondering about the cause of the SIGPIPE here. The case presented sounds convincing but still seems to depend on a few assumptions? You have caught some lines from the logfiles for worker and database. But wasnt there any further lines in koha-worker-output about the crash? This would give us more info about the line in the worker script. Now we are guessing? Or do I miss something? When worker lost the connection, I would expect DBIx to just raise an exception? The background worker does not catch it, so perl exits probably with 255 ? And daemon respawns (but without 13?) When I hear about SIGPIPE, I would first look for problems between parent and child processes since we are forking here via Parallel::ForkManager. Also note that this depends on a koha-conf setting. background_jobs_worker/max_processes What value do you use there? If there is a database connection problem in the child process, and we did not configure P::F correctly (?), could that trigger a SIGPIPE ? Note that process_job has a try..catch block. But what if $job->process dies on a database issue, then we try $job->store in the catch block?! And trigger a new error that is not caught? And what about the I/O layers? I didnt find any information about what P::F exactly does with these? Just the same as fork (inheriting them in child)? Should we eval the job->status->store in the catch block of sub process_job to get wiser? Note that these are just questions. Wondering if we are looking in the wrong direction somehow. But I could very well be mistaken. -- 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/
