https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35111 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #10)
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?
There's nothing in the worker-output.log in this case. That's part of what made it challenging to troubleshoot initially.
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?)
That's the issue. DBIx has reconnect logic, and on Debian with the mariadb client libraries it handles this without any exceptions or issues. On Ubuntu with the mysql client libraries a SIGPIPE signal gets generated. In Starman/Plack, SIGPIPE is ignored, so the DBIx can just reconnect. In the background jobs worker, the SIGPIPE is not ignored and it causes the process to crash.
When I hear about SIGPIPE, I would first look for problems between parent and child processes since we are forking here via Parallel::ForkManager.
I looked at all the different sockets and pipes. It's the database one that's the problem.
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 ?
It's not the child process. It's the parent process. The stacktrace shows that. -- You are receiving this mail because: You are watching all bug changes.