Image: nfrastack/freescout:latest (reported as 2.2.9, FreeScout 1.8.239), observed 2026-09-04.
Symptom: System Status shows queue:work — Last run: ? / Last successful run: ? while mail sending and fetching work correctly. Clearing the cache doesn't help — nothing in FreeScout core populates queue_work_last_run.
Cause — the image runs its own worker, but not the way FreeScout detects one.
-
41-freescout-scheduler/run:31 runs artisan schedule:run --no-interaction.
-
FreeScout intentionally suppresses its built-in worker under that flag. Per Kernel.php:25: "If --no-interaction flag is set the script will not run 'queue:work' daemon." Enforced at Kernel.php:192-197.
-
This is expected — but it also skips the line where FreeScout would have tagged the worker, Kernel.php:205:
$queue_work_params['--queue'] .= ','.\Helper::getWorkerIdentifier();
// "Add identifier to avoid conflicts with other FreeScout instances on the same server."
-
The image's own worker, 40-freescout-worker/run:25, starts:
queue:work --queue='emails,default' --sleep=5 --tries=1 --timeout=1800
— without the identifier.
-
Detection is a process grep, SystemController.php:104:
$ps_output = \Helper::shellExec("ps auxww | grep '{$command_identifier}'");
No match → ?.
Identifier: md5(APP_KEY) — Helper::getWorkerIdentifier() at Helper.php:1772. Not getAppIdentifier() (Helper.php:1751), which is md5(APP_KEY + APP_URL host).
Both scheduler modes are affected — SCHEDULER_TYPE=cron is not a workaround; /container/functions/40-freescout:166 also passes --no-interaction.
Workaround: append the identifier to the worker's --queue. Verified: status page reports Running again.
Suggested fix: have 40-freescout-worker derive md5(APP_KEY) and append it to --queue, matching what core does at Kernel.php:205.
Minor: the comment at Kernel.php:192 says --no-daemonize while the code checks --no-interaction.
Image: nfrastack/freescout:latest (reported as 2.2.9, FreeScout 1.8.239), observed 2026-09-04.
Symptom: System Status shows queue:work — Last run: ? / Last successful run: ? while mail sending and fetching work correctly. Clearing the cache doesn't help — nothing in FreeScout core populates queue_work_last_run.
Cause — the image runs its own worker, but not the way FreeScout detects one.
41-freescout-scheduler/run:31 runs artisan schedule:run --no-interaction.
FreeScout intentionally suppresses its built-in worker under that flag. Per Kernel.php:25: "If --no-interaction flag is set the script will not run 'queue:work' daemon." Enforced at Kernel.php:192-197.
This is expected — but it also skips the line where FreeScout would have tagged the worker, Kernel.php:205:
$queue_work_params['--queue'] .= ','.\Helper::getWorkerIdentifier();
// "Add identifier to avoid conflicts with other FreeScout instances on the same server."
The image's own worker, 40-freescout-worker/run:25, starts:
queue:work --queue='emails,default' --sleep=5 --tries=1 --timeout=1800
— without the identifier.
Detection is a process grep, SystemController.php:104:
$ps_output = \Helper::shellExec("ps auxww | grep '{$command_identifier}'");
No match → ?.
Identifier: md5(APP_KEY) — Helper::getWorkerIdentifier() at Helper.php:1772. Not getAppIdentifier() (Helper.php:1751), which is md5(APP_KEY + APP_URL host).
Both scheduler modes are affected — SCHEDULER_TYPE=cron is not a workaround; /container/functions/40-freescout:166 also passes --no-interaction.
Workaround: append the identifier to the worker's --queue. Verified: status page reports Running again.
Suggested fix: have 40-freescout-worker derive md5(APP_KEY) and append it to --queue, matching what core does at Kernel.php:205.
Minor: the comment at Kernel.php:192 says --no-daemonize while the code checks --no-interaction.