Cloudron Forum

The queue is working, but the fetching is not working now. After a minute of restarting the server, the fetching stopped.

480	
479	[2025-01-29 16:31:26] Fetching finished
478	[2025-01-29 16:31:25] Fetched: 0
477	[2025-01-29 16:31:25] Folder: Archive
476	[2025-01-29 16:31:25] Fetched: 0
475	[2025-01-29 16:31:25] Folder: Trash
474	[2025-01-29 16:31:25] Fetched: 0
473	[2025-01-29 16:31:25] Folder: Sent
472	[2025-01-29 16:31:25] Fetched: 0
471	[2025-01-29 16:31:25] Folder: Spam

EDIT:
After 20 minutes it's now fetching again. Let's see if it keeps working now.

Hi @girish,

Thank you for your prompt response, the technical stuff seems correct now that you mention the supervisor.

The main issue we had is that the queue was not running.

I've just checked the supervisor and see that the artisan-queue was crashed.

/app/code# supervisorctl status
apache2                          RUNNING   pid 223, uptime 1 day, 2:46:07
artisan-queue                    FATAL     Exited too quickly (process log may have deta
ils)

/app/code# supervisorctl tail artisan-queue
artisan-queue: ERROR (unknown error reading log)

After removing our CRON command to run the schedule and restarting the Freescout Service I can now see the artisan-queue running. Even though if I do:

supervisorctl tail artisan-queue

I still see

artisan-queue: ERROR (unknown error reading log)

Not sure if this is an issue or not, but the queue is now working
Hope it stays like this.

Best regards,
Phil

Hi Cloudron team,

We've encountered an issue with the default CRON configuration for the FreeScout app on Cloudron.

The default CRON script installed for FreeScout is as follows:

#!/bin/bash

set -eu

cd /app/code

echo "=> Run cron tasks"

# when run with --no-interaction it will not daemonize (unlike in the supervisor config for it)
/usr/local/bin/gosu www-data:www-data php artisan schedule:run --no-interaction

The problem lies in the --no-interaction flag. According to FreeScout's official documentation (link), this flag should NOT be added to the command, as it prevents the background queue:work daemon from running. This behavior is exactly what we're experiencing.

Unfortunately, we cannot modify the default CRON file in /app/pkg/cron.sh since it is read-protected. Additionally, when we attempt to add the correct CRON command to the Cloudron CRON section:

* * * * * php /app/code/artisan schedule:run >> /dev/null 2>&1

It results in duplicate CRON jobs being executed, further complicating the situation.

Could you please advise on how to resolve this? Ideally, we need the default CRON script adjusted to align with FreeScout's documentation or an alternative solution that allows us to override the existing configuration without conflicts.

Thanks for your assistance!

Best regards,
Phil