Stuck jobs in health check that don't clear

Self-Hosted | v5
1

Help please.

Recently, my self-hosted v5,12,26 installation has started showing a number of ‘Pending Jobs’ next to the orange triangle, that appear to go up every few days (basically after jobs get created).

Failed jobs are at zero, though, these are just increasing ‘pending jobs’

Running the CLI commands for flushing or clearing the queue only returns that there are no jobs to clear or to flush.

I’ve checked file permissions, and they are all correct (or at least appear to be).

Checking caravel logs, this is the only error that appears to stand out:

[2025-05-03 04:38:16] production.ERROR: SQLSTATE[HY000] [2002] No such file or directory {“exception”:"[object] (PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory>

----> WHAT FILE OR DIRECTORY is it referring to that it can’t fine? That’s the part I can’t figure out.

#0 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connectors/Connector.php(66): PDO->__construct()

#1 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connectors/Connector.php(85): Illuminate\Database\Connectors\Connector->createPdoCon>

#2 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connectors/Connector.php(48): Illuminate\Database\Connectors\Connector->tryAgainIfCa>

#3 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connectors/MySqlConnector.php(24): Illuminate\Database\Connectors\Connector->createC>

#4 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connectors/ConnectionFactory.php(185): Illuminate\Database\Connectors\MySqlConnector>

#5 [internal function]: Illuminate\Database\Connectors\ConnectionFactory->Illuminate\Database\Connectors\{closure}()

#6 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Connection.php(1231): call_user_func()

#7 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php(187): Illuminate\Database\Connection->getPdo()

#8 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php(153): Illuminate\Database\Connection->handleBeginTra>

#9 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php(127): Illuminate\Database\Connection->createTransact>

#10 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php(26): Illuminate\Database\Connection->beginTransacti>

#11 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/DatabaseQueue.php(226): Illuminate\Database\Connection->transaction()

#12 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(351): Illuminate\Queue\DatabaseQueue->pop()

#13 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(366): Illuminate\Queue\Worker->Illuminate\Queue\{closure}()

#14 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(164): Illuminate\Queue\Worker->getNextJob()

#15 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(149): Illuminate\Queue\Worker->daemon()

#16 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(132): Illuminate\Queue\Console\WorkCommand->runWorker()

#17 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Illuminate\Queue\Console\WorkCommand->handle()

#18 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()

#19 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(95): Illuminate\Container\Util::unwrapIfClosure()

#20 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\Container\BoundMethod::callBoundMethod()

#21 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/Container.php(696): Illuminate\Container\BoundMethod::call()

#22 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Console/Command.php(213): Illuminate\Container\Container->call()

#23 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/symfony/console/Command/Command.php(279): Illuminate\Console\Command->execute()

#24 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Console/Command.php(182): Symfony\Component\Console\Command\Command->run()

#25 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/symfony/console/Application.php(1094): Illuminate\Console\Command->run()

#26 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand()

#27 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()

#28 /var/www/billing.pacbill.me/htdocs/invoiceninja/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\Component\Console\Application->run()

#29 /var/www/billing.pacbill.me/htdocs/invoiceninja/artisan(35): Illuminate\Foundation\Console\Kernel->handle()

#30 {main}

2

Hi,

I’m not sure, maybe this answer from ChatGPT will help:

Gotcha—here’s what’s (almost certainly) happening and how to fix it.

What the orange “Pending Jobs” means

Invoice Ninja’s badge is counting jobs sitting in your queue that aren’t being processed. Because nothing is actually picking them up, the count rises whenever the app enqueues email/notifications/PDF jobs. “Failed jobs = 0” just means they never even got as far as failing—they’re stuck pending.

Why it’s happening (the smoking gun)

Your log error:

SQLSTATE[HY000] [2002] No such file or directory

That’s classic MySQL “socket vs TCP” trouble. In Laravel/PDO:

  • DB_HOST=localhost → PHP tries a UNIX socket. If the socket path doesn’t exist in the container/host, you get “No such file or directory”.
  • DB_HOST=127.0.0.1 (or a Docker service name like mysql) → PHP uses TCP, which avoids the socket.

What typically happens is: your queue worker (Supervisor/Horizon/worker container) is using environment where DB_HOST=localhost, so it can’t connect to MySQL. The web app might be fine (different ENV), but the worker can’t reach the DB, so jobs never run.

Quick checklist (do these in order)

  1. Fix DB host

    • In your .env, set one of:

      • DB_HOST=127.0.0.1 (bare-metal/single host)
      • or in Docker: DB_HOST=mysql (whatever your DB service is named)

    • Do not use localhost unless you also set a valid DB_SOCKET=/path/to/mysqld.sock.

  2. Make sure the worker reads the same .env

    • If you’re using Supervisor on the host, confirm it’s starting the app from the same directory as the .env.
    • If you’re on Docker/DigitalOcean App Platform: ensure the worker container has the same env vars as the web container.

  3. Restart workers so they reload config

    php artisan optimize:clear
php artisan config:clear
php artisan queue:restart
# If using Supervisor:
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart all
# If using Docker:
docker compose restart <worker-service>

  4. Verify the queue is actually processing

    • If using database queue:

      php artisan queue:work database --queue=default,high --tries=3
# In SQL:
select count(*) from jobs;

      That number should begin to drop as the worker runs.

    • If using Redis:

      redis-cli LLEN queues:default
php artisan queue:work redis --queue=default,high --tries=3

  5. Cron is still needed
    Ensure your scheduler is firing every minute (for recurring tasks, reminders, etc.):

    * * * * * cd /path/to/your/app && php artisan schedule:run >> /dev/null 2>&1

  6. Supervisor example (if you need one)

    [program:in-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/invoiceninja/artisan queue:work --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
numprocs=2
redirect_stderr=true
stdout_logfile=/var/log/supervisor/in-queue.log
stopwaitsecs=3600

    After editing, run supervisorctl reread && supervisorctl update && supervisorctl restart in-queue:*.

About “queue:clear” / “queue:flush”

  • php artisan queue:flush clears failed jobs for Redis/SQS—not pending jobs. Seeing “no jobs to flush” is expected.

  • To nuke pending jobs (not recommended unless you accept losing them):

    php artisan queue:clear database --force
# or for redis:
php artisan queue:clear redis --force

File permissions

Good to check, but this specific error points squarely at the DB connection used by the worker, not filesystem rights.

TL;DR fix

Change DB_HOST (and/or add DB_SOCKET correctly) so the worker can reach MySQL, then restart the queue worker so it picks up the .env. Once the worker is actually connected, the Pending Jobs badge will start counting down as jobs are processed.

3

Wow, OK, I’ll check on these fix/tasks when I get home. That’d be marvelous if the fix is that easy.

Strangely enough, this install had worked just fine for a while, and only started acting up since I’d done the first update.

4

Did this, running queue:work

The Jobs number is NOT going down. I’ll let it run overnight, but we might not have fixed this.

I might end up flushing and clearing those jobs (don’t mind losing them, I can restart them manually), but it’s odd this didn’t fix it. (database setting was set to localhost, which I’ve changed to 127.0.0.1)

I’ve also switched to Redis, and done the respective clear/optimize/restart, and am now running

php artisan queue:work redis --queue=default,high --tries=3

and letting it run overnight, to see how that goes

5

Didn’t have long to wait - zero pending jobs. In fact, now no jobs (pending or failed) are displayed). Could this merely be because Redis configuration doesn’t show or expose database jobs?

6

I think you may need to use the CLI to check the pending jobs with Redis.

7

What’s command for that?

8

Any plans for supporting Redis/Jobs in the apps?

9

OK, so I switched back to database (away from Redis), and the 44 ‘pending jobs’ are back.

So, I attempted ‘artisan queue:clear database --force’ - and it didn’t delete those 44 jobs.

So, seriously, what’s going on here? Obviously, these queue specific commands all appear to be dealing with the ‘default’ queue, and I speculate that this mysterious ‘44 pending jobs’ is a different queue, and not whatever the ‘default’ queue is.

What other means do I have to see what other queues there are, since there is, by all appearances, another queue in play?

10

I have had the same issue- Everything was GREAT in V4.
I updated to Version 5 and it doesn’t work. It is on shared hosting. I have spend months on this… Is it possible the softaculous updater is not working properly?

11

This recently resolved issue may be related.

12

OK, so that did it.

queue:work database --queue=scout

Executed all of the pending jobs.

The fix is, apparently, updating to .27 (which I’ll do next).

It would have been helpful to be aware that there is an additional queue called ‘scout’, so that ’ queue:work database --queue=scout’ could have helped to at least clear the queue.

13

After the update, the ‘pending jobs’ queue still kept accumulating ‘pending jobs’. So, nothing changed. This wasn’t a fix.

My .env had SCOUT_DRIVER=null already set, yet my ‘pending jobs’ kept accumulating jobs.

I did notice that SCOUT_DRIVER=null had a non-printing character at the end. I removed that and restarted web server and FPM. Waiting to see if this now resolves.

Running artisan queue:work database --queue=scout cleared a whole bunch of Laravel\Scout\Jobs\MakeSearchable jobs, so not sure if that helps to track down this issue…

Let’s see if that non-printing character was the problem or if this bug keeps creating pending jobs… Either way, these all seem to be ‘MakeSearchable’ jobs, that have no impact on actual operation, but still…

1 Like
14

The same thing happens to me, even having the updated version.

15

Removing that character had zero effect. ‘scout’ pending jobs keep accumulating as before.

Any suggestions?