Already tried deleting everything and setting it up a second time, but wiki-task is complaining about another processRunner? - there is only one bluespice-wiki-task container.
Expected behavior:
A clear description of what you expected to happen.
What was the error message/error log?
docker log:
bluespice-wiki-task | Starting process 92462ae9ac659d6ba580238c359cdb34...Finished
bluespice-wiki-task | Starting process 5722891337ea4aec1628e5607ca45858...Finished
bluespice-wiki-task | Starting process a34ef4cfe21bf0769c3052414e1c53e3...Finished
bluespice-wiki-task | Starting process 2d53831afa8ded6774b8e9c5aa8b7b03...Finished
bluespice-wiki-task | Starting process 90f62aab7bd530dbc33f155abcac107a...Finished
bluespice-wiki-task | Starting process 678380a7de857d3e8fdc164a30068415...Finished
bluespice-wiki-task | Starting process c27d4f0e2ce0febaa4ff667f790c3b01...Finished
bluespice-wiki-task | Starting process 0222010aa356e6b0610eec2fbfd5ad25...Finished
bluespice-wiki-task | Starting process 7536812813c87514001370841d0d8f4b...Finished
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-wiki-task | ProcessRunner with these arguments is already running
bluespice-proxy | nginx.1 | wikitest.banana.local 172.18.0.1 - - \[17/Nov/2025:20:31:03 +0000\] "GET / HTTP/1.0" 503 190 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0" "-"
Screenshots
If applicable, add screenshots to help explain your problem.
I retried with the latest deployment script + version 5.1.3 + free edition, and could not reproduce the reported behavior in this thread. Here’s what I can think of for debugging:
Please run ./bluespice-deploy down in your compose directory, make sure that there’s no BlueSpice relevant containers left in your docker ps out put, then retry ./bluespice-deploy up -d
Please check output docker logs -f bluespice-wiki-task. If the automatic installation is correct, the output should be like the following block with some messages repeating regularly. If there’s any error messages/tracebacks, please share in this post.
🏇 Starting TaskRunner
Starting update
No version change, skipping updates
Starting runJobs
Starting ProcessRunner
Starting SnapshotStatistics cronjobs
time="2025-11-24T18:44:12+01:00" level=warning msg="process reaping disabled, not pid 1"
time="2025-11-24T18:44:12+01:00" level=info msg="read crontab: /app/cron/snapshot-statistics"
Started executing runjobs service
Starting run
2025-11-24 17:44:12 invokeRunner RunJobsTriggerRunner namespace=0 title=RunJobsTriggerRunner requestId=68b3c5a394c3c860f18a95ea (id=633,timestamp=20251124174412) STARTING
2025-11-24 17:44:12 invokeRunner RunJobsTriggerRunner namespace=0 title=RunJobsTriggerRunner requestId=68b3c5a394c3c860f18a95ea (id=633,timestamp=20251124174412) t=1 good
Cooldown for 5 seconds
Starting run
Please run docker exec -it bluespice-wiki-task and the processes with ps aux --forest, normally you should see something like this:
If you are wiring your self-built BlueSpice code base, I recommend that you use branch REL1_43-5.1.x, see GitHub - hallowelt/mediawiki at REL1_43-5.1.x . The REL1_43 branch already contains many changes specific for BlueSpice 5.2.something, which might be incompatible with the deployment script you are using (main branch or 5.1.3 tag).
Great that your process runner is back working again!
The tmp file you cleaned is like a lock file (making sure that there is only one process runner running), containing a json with one key-value pair. The value should be the PID of the php ... mwstake/mediawiki-component-processmanager/maintenance/processRunner.php ... process you see in the forest, which should be “32” in your case.
To reset all non-persistent data within containers, for example those in the /tmp directory, ./bluespice-deploy down should be a better option as ./bluespice-deploy stop, as in the former case the containers are recreated. The wiki data in a BlueSpice instance is already made persistent (database, attachments, configs, search index, domain certificates etc.).
nvm - back to the same chaos. i ran down and restarted it:
🏇 Starting TaskRunner
Starting update
No version change, skipping updates
Starting runJobs
Starting ProcessRunner
Starting Backup-Agent
Backup daily at 02
Starting SnapshotStatistics cronjobs
Starting ProcessRunner
Using queue: BlueSpice\WikiFarm\ProcessQueue\FarmProcessQueue
Using plugins: wikicron
ProcessRunner with these arguments is already running
ProcessRunner with these arguments is already running
ProcessRunner with these arguments is already running
I observed something similar to your report when working on a BlueSpice instance. In this instance, there was an especially resource-consuming task in the list, triggering timeout of the job runner on each scheduled run. When checking using php maintenance/showJobs.php, I noticed that there are already 4000+ jobs remaining and would not decrease at another recheck minutes later. For this instance, I ran php maintenance/runJobs.php manually to force finish the blocking tasks on the list (ctrl + c to cancel manual job running after overcoming the slow one), then the task runner could eventually get rid of the remaining jobs. The showJobs number dropped down to 0 soon afterwards.
Can you please check if you are also experiencing something alike?
Greetings,
Hua
(P.S. New Docker images for BlueSpice 5.1.4 have been released yesterday, containing improvements in the base images as well)
What i found is that this happens when the External URL (WIKI_HOST) does not resolve to the wiki this happens (instead of saying is not reachable)
Re-reading your post, maybe you meant these:
the hosts/dns setup resolves wikitest.banana.local to your wiki service
but the WIKI_HOST is actually something like wikitest.orange.local
when you visit wikitest.banana.local, you only get 503 error
If so, it is kind of the design of the bluespice/proxy service, filtering incorrect visits. I can understand the confusion while configuring though. Thanks for the discussion still!