If RabbitMQ is on the same host that koha then koha_worker is started too early and it is unable to connect to RabbitMQ so it fallback to polling. Example with koha-testing-docker rabbitmqctl list_channels Listing channels ... root@kohadevbox:kohadevbox$ No channels. $ restart_all Restarting Apache httpd web server: apache2. Restarting Koha ILS: koha-commonStopping Plack daemon for kohadev:. Stopping Z39.50/SRU daemon for kohadev:. Stopping Koha worker daemon for kohadev (default):. Stopping Koha worker daemon for kohadev (long_tasks):. Stopping Koha indexing daemon for kohadev:. Starting Plack daemon for kohadev:. Starting Z39.50/SRU daemon for kohadev:. Starting Koha worker daemon for kohadev (default):. Starting Koha worker daemon for kohadev (long_tasks):. Starting Koha indexing daemon for kohadev:. . root@kohadevbox:kohadevbox$ rabbitmqctl list_channels Listing channels ... pid user consumer_count messages_unacknowledged <rabbit@kohadevbox.1663923239.864.0> guest 1 0 <rabbit@kohadevbox.1663923239.883.0> guest 1 0 root@kohadevbox:kohadevbox$ or double check with ss -ntp port 61613 connections.
I'm not having this problem in prod on Ubuntu
(In reply to David Cook from comment #1) > I'm not having this problem in prod on Ubuntu Are rabbitmq and koha-worker.service running on the same host, i.e. connecting using 127.1 ?
(In reply to Didier Gautheron from comment #2) > (In reply to David Cook from comment #1) > > I'm not having this problem in prod on Ubuntu > > Are rabbitmq and koha-worker.service running on the same host, i.e. > connecting using 127.1 ? There's no koha-worker.service when you're using Debian packages. But yes RabbitMQ and the background_jobs_worker.pl processes are all running on the same host and communicating using "localhost" as the hostname for the RabbitMQ.