Queue not working - Invoices not being sent - "No scheduled commands are ready to run."

Self-Hosted | v5
1

As of late, the queue via database has stopped working.

If I use “sync” as the queue type in the .env, everything works fine and invoices are sent out.

Usually I use database for the queue and I have a cron job set up under the web server and it was previously working fine until an invoice ninja update recently.

If I use database, even if I manually run php artisan schedule:run >> /dev/null 2>&1 in the invoiceninja directory with things in the queue (I can see jobs in the jobs table in the database), nothing happens. The command just runs and there are no errors. If I do it without the /dev/null, it says either:
“No scheduled commands are ready to run.”

or

[2022-03-12T15:35:37+00:00] Running scheduled command: Callback

[2022-03-12T15:35:37+00:00] Running scheduled command: ‘/usr/bin/php7.4’ ‘artisan’ queue:restart > ‘/dev/null’ 2>&1

Even though there are things in the queue, they aren’t being processed.

I have tried directly specifying /usr/bin/php7.4 when running the command, not just php. I have tried artisan optimizes, I have rebooted my server etc. For some reason no matter what I try now, the queue via database no longer works. It was working absolutely fine up until recently.

Any ideas?

2

Hi,

@david any thoughts?

3

@kylegp

What has changed in your setup?

4

@david I moved invoiceninja over to a new server but otherwise I kept everything the same. The only difference is I’m using virtualmin to administer my new box but I’ve checked all my configs and everything is the same as it was on my old server.

After I migrated everything, I ran the schedule command once manually and it processed the queue. However subsequent tests or cron just do nothing as described above. Everything works except this queue and I’m stumped.

5

Which users are you running the crons under?

Also ensure the webuser can write to storage/*

6

The crons are running under the user/owner for the virtualhost and permissions are correct.

I just got it working (including cron) after running php artisan cache:clear. Looks like perhaps there was some bad cache from the migration causing the issue.