In rare conditions it may happen that the scheduler daemon of OTRS / Znuny may run into following issue and you get tons of tickets generated by the scheduler.
Subject: OTRS Scheduler Daemon Cron: ArticleSearchIndexRebuild Body: Error: Active indexing process already running! Skipping...
This maybe caused by triggering the ArticleSearchIndexRebuild manually like described in OTRS / Znuny search tuning with rebuilding ArticleSearchIndex or by restarting OTRS/Znuny during the Scheduler was running the Rebuild (very probable) and could not terminate properly. On most distributions the stopping of the daemons is limited by a hard limit, e.g. on Ubuntu it is 90 seconds. If the daemon takes longer the process is getting killed/terminated hard. In this case often the Scheduler PID is left over in the database table process_id
How to stop the error tickets of ArticleSearchIndexRebuild?
To fix it it is best to run a forced rebuild on 1 article:
sudo -u otrs /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndexRebuildWorker --children 1 --limit 1 --force-pid
The command returns fast and it does the cleanup on the database too.
Now check if the new tickets disappeared
if top is showing you perl processes at about 100% CPU usage. This is only the case if you have a huge article base to reindex. For more insights read OTRS / Znuny search tuning with rebuilding ArticleSearchIndex
Why are you getting the above issue (ir)regularly?
This error happens commonly during your worker FulltextIndexRebuildWorker is failing during processing, by not getting the required amount of database connections.
Often the first issue you get is a ticket like this:
DBI connect('database=otrs;host=127.0.0.1','otrs',…) failed: Too many connections at /opt/znuny-6.4.2/Kernel/System/DB.pm line 209. ERROR: OTRS-otrs.Console.pl-Maint::Ticket::FulltextIndexRebuildWorker-10 Perl: 5.30.0 OS: linux Time: Fri Nov 25 15:31:26 2022 Message: Too many connections Traceback (52753): Module: Kernel::System::DB::Do Line: 468 Module: Kernel::System::PID::PIDDelete Line: 225 Module: Kernel::System::Console::Command::Maint::Ticket::FulltextIndexRebuildWorker::PostRun Line: 250 Module: (eval) Line: 467 Module: Kernel::System::Console::BaseCommand::Execute Line: 467 Module: (eval) Line: 143 Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 122 Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 236 Module: (eval) Line: 331 Module: main::Start Line: 331 Module: /opt/otrs/bin/otrs.Daemon.pl Line: 152 Error: Unable to unregister indexing process! Skipping…
A common case here is, that you have power users open at the same moment tons of new tabs, e.g. to read/search in a mass of tickets some details. Each browser tab causes that Znuny is opening a new connection to the database. And thus not enough database connections are available to finish the processing of FulltextIndexRebuildWorker.
A simple workaround for such issues is to increase the max allowed parallel connections to the database. With MariaDB or MySQL this can be done with:
max_connection = 200
to allow 200 parallel connections.
be careful, that you hardware and OS is configured well for that amount of load and connections, which now Znuny could cause. Especially if you run virtual machines, you have to be even more careful!