Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. FreeScout
  3. Issue with Default CRON Configuration for FreeScout App

Issue with Default CRON Configuration for FreeScout App

Scheduled Pinned Locked Moved FreeScout
5 Posts 2 Posters 321 Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      R Offline
      rnphil
      wrote on last edited by
      #1

      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

      girishG 1 Reply Last reply
      2
      • R rnphil

        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

        girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #2

        @rnphil We use FreeScout for our email support and it seems to work fine. Can you tell us what is the issue you are facing? Is FreeScout not fetching mails?

        Now about the technical stuff... AFAICT, the configuration is correct:

        • There is a supervisor process running in background. https://git.cloudron.io/packages/freescout-app/-/blob/master/supervisor/artisan-queue.conf?ref_type=heads . This runs php artisan schedule:run and is the background queue . You can see this with supervisorctl status in web terminal of FreeScout.

        • The cron job runs with php artisan schedule:run --no-interaction .

        1 Reply Last reply
        0
        • R Offline
          R Offline
          rnphil
          wrote on last edited by
          #3

          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

          girishG 1 Reply Last reply
          1
          • R rnphil

            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

            girishG Offline
            girishG Offline
            girish
            Staff
            wrote on last edited by
            #4

            @rnphil said in Issue with Default CRON Configuration for FreeScout App:

            After removing our CRON command to run the schedule

            Cloudron packages always configure the required cron in the package itself. So, if you find something like this, usually it's a package bug . The cron section of the app is meant for your own custom cron jobs (and not for things which the app needs).

            1 Reply Last reply
            0
            • R Offline
              R Offline
              rnphil
              wrote on last edited by rnphil
              #5

              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
              

              959c9c52-cd92-4f2a-811c-2c453343c522-image.png

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

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Bookmarks
                • Search