The attempt to merge branch 3.3.x into master has completed after considering the changes in this PR.

• Merge result: Conflict ❌

A separate PR will be needed to merge 3.3.x into master.

I dug into the red PHP 7.2 - mariadb:10.3 job — it's the only mysql/mariadb leg that ran to completion (the other sixteen were cancelled by fail-fast, and the green jobs are all legs where this test skips), so there's no green counter-example for the new flow. I reproduced the failure mechanics outside CI with the same Ubuntu sphinxsearch 2.2.11 package, the generated sphinx.conf from this PR's setup script, a 3.3.17 board database on MySQL 8.0, and queries through includes/sphinxapi.php the same way fulltext_sphinx does. It's deterministic, not flakiness — three things stack up:

1. Nothing starts searchd any more. The setup script now ends with sudo service sphinxsearch stop, and the test dropped the service sphinxsearch start call. With no daemon, the sphinx client gets connection refused on port 9312 (errno=111), search.php renders zero results, and the assertion fails exactly as in CI (Failed asserting that 0 matches expected 1).

2. Starting it in the setup script instead can't work either: searchd 2.2.11 refuses to start before the first index build — FATAL: no valid indexes to serve (and at setup time the test database doesn't even exist yet). That's why the old flow had to stop → indexer --all → start from inside the test.

3. Unprivileged indexer --all --rotate can't signal a service-run searchd at all. searchd creates its pid file mode 0600 owned by sphinxsearch, so indexer running as the CI user reports WARNING: failed to open pid_file '/var/run/sphinxsearch/searchd.pid' + WARNING: indices NOT rotated and exits with code 2 — and even with a readable pid file, sending SIGHUP to another user's process is EPERM. Because the new exec() discards $output/$retval, all of this is invisible and the test just sees 0 results.

The no-sudo goal is very much achievable though — I verified this variant end-to-end locally: run both indexer and searchd as the test user and drop the service wrapper entirely:

• setup-sphinx.sh: chown the data dir to the CI user instead of sphinxsearch, and leave the service alone (it never needs to run);
• create_search_index(): exec('indexer --all', $output, $retval) for the first build, then start the daemon directly with exec('searchd --config /etc/sphinxsearch/sphinx.conf') — no sudo needed when it's the same user; subsequent rebuilds via indexer --all --rotate then work (successfully sent SIGHUP to searchd);
• tearDown: searchd --config /etc/sphinxsearch/sphinx.conf --stopwait (verified: exits 0, daemon gone, port closed).

Two robustness notes from the same testing: asserting $retval === 0 (and including $output in the message) would have made every failure above loud instead of silent; and --rotate is asynchronous — after indexer exits, searchd kept serving the old index for ~50 ms on my machine before swapping, so an assertion immediately after re-indexing has a flaky window. A short poll/wait after --rotate, or the synchronous stop → indexer --all → start sequence, closes it.

(The skip logic itself — Windows, missing indexer, non-MySQL — works nicely; the phpbb_functional_visibility_softdelete_test::test_split_topic failure in the same job I couldn't attribute; it may be a knock-on of the search backend state or an independent flake.)