I have two websites running identical laravel 5.5 project. In fact both websites hosted on the same server. One of them works, another one has troubles with queues. I have double-checked everything.
.env:
...
BROADCAST_DRIVER=log
CACHE_DRIVER=file
SESSION_DRIVER=database
QUEUE_DRIVER=database
...
conf/queue.php
'database' => [
'driver' => 'database',
'table' => 'jobs',
'queue' => 'default',
'retry_after' => 90,
],
I do have empty jobs table as well.
Whenever I do try to run queues I'm getting an error
php artisan queue:work --daemon
In QueueManager.php line 172:
No connector for []
Please check the config queue drive setting. If use Redis, you can use php artisan tinker check
current the config.
Check command queue:
php artisan queue:work redis --queue=QUEUE_NAME --tries=3 --memory=128 --timeout=300
Check job listen by command line:
ps aux | grep php
I just had to specify a "connection" (database for my case) after queue:work command like below:
php artisan queue:work database --queue=Q_NAME
and the error disappeared!
Hi I encountered the same problem and couldn't find the solution but I followed laravel deploy optimizations, like cache config, view and routes which result into this. (I am not sure why).
I followed these and it worked like magic. (I don't know why it worked)
php artisan config:clear
php artisan route:clear
php artisan view:clear
Related
Edit:
php artisan config:cache work nice, but now I got other problem.
the URL giving me Error 500
I upload a project to a new subdomain area after I changed .env file
when I open URL I still got an error with the old database and user
I tried to check online with the .env file but - I don't know where he stored this database, I tried to see where is this name with ctrl+f but - nothing found
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=faceterc_hot
DB_USERNAME=faceterc_hot
DB_PASSWORD=testpro
I expect to get the same error maybe but not with the old database name.
and this gives me a indicate that maybe the file or something not changed or he using the other details from I don't know where
Good, practice for, If you change in a .env file first restart the server using below command.
php artisan serve
then after run below more command for clear old cache and config.
composer dump-autoload
php artisan config:cache
php artisan config:clear
You can simply do a
php artisan config:cache
In case you are on a shared hosting, you can change the values in config/database.php to only use the set values in your .env. Setting it like this will make sure, it only use the .env values.
mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST'),
'database' => env('DB_DATABASE'),
'username' => env('DB_USERNAME'),
'password' => env('DB_PASSWORD'),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
php artisan config:clear Solve the problem with DATABASE error
just ran :
php artisan config:clear
with ssh at the main folder.
Just execute
php artisan config:cache
as the laravel cache's the environment files rather than accessing the data from it on every request.
It's always a good practice to run these couple of commands when you change any environment related variable:
php artisan config:clear
php artisan cache:clear
Execute these commands:
php artisan config:cache
php artisan route:cache
php artisan optimize
That will clear your env cache and it should do.
I have a strange behavior when a Job runs:
On dev server (win 7 php 7.2.10) everything work fine,
on the production server Linux centOS php 7.0.10 it throws an Exception:
Illuminate\Queue\MaxAttemptsExceededException: A queued job has been attempted too many times. The job may have previously timed out.
config/queue.php
'database' => [
'driver' => 'database',
'table' => 'jobs',
'queue' => 'default',
'retry_after' => 90,
],
this happens after a job is queued ... when it starts working ... after about 30 seconds (Failed)
the exception is in the failed_jobs table
I though it could be dependent by the php max_execution_time directive but when i do
php -r "echo ini_get('max_execution_time') . PHP_EOL;"
it shows me zero (no timeout ... which is correct)
the Job is queued in this way:
dispatch((new Syncronize($file))->onQueue('sync'));
The Sincronize Job has no timeout (has 1 try) and simply calls two artisan commands which work perfecly both on prod and on dev server if called from the shell.
https://pastebin.com/mnaHWq71
to start jobs on the dev server I use
php artisan queue:work --queue=sync,newsletter,default
on prod server I use this
https://pastebin.com/h7uv5gca
any idea of what can be the cause ?
Found the problem ...
was in my service /etc/init.d/myservice
cd /var/www/html/
case "$1" in
start)
php artisan queue:work --queue=sync,newsletter,default &
echo $!>/var/run/myservice.pid
echo "server daemon started"
;;
I didn't check if the process was already running so I launch it twice.
I saw 2 processes in ps axu and seems that this was the cause
This check solved
if [ -e /var/run/myservice.pid ]; then
echo "Service is running. Call stop first".
exit 1
fi
When am trying to migrate anything , then every-time it's asking me about
Do you want to run ".env" instead? (yes/no) [no]:
I added .env file in my project. also i tried to solve this problem with this below changes :
config/app.php
'.env' => env('APP_ENV', 'development'),
'debug' => env('APP_DEBUG', true),
.env file below :
APP_ENV=local
APP_DEGUG = true
i also tried to fix this problem with
php artisan config:clear
after this
php artisan key:generate
Nothing changes when i checked this current mode by :
php artisan env
It's showing me
Current application environment: production
how to solve this ?
I had this problem too, and these steps helped me:
clear config
php artisan config:clear
after this php artisan key:generate
now cmd say me its local
php artisan env
There's a typo:
Not:
'.env' => env('APP_ENV', 'development'),
But:
'env' => env('APP_ENV', 'development'),
without dot before env
Some time ago I asked about setting env settings and how to properly use them. I was quickly pointed to a comparable question and I found out that indeed it was bad practice to use env('KEY') throughout your code.
So now I am in the process of migrating my env settings to config/app.php.
However, if I play with Tinker, the env variables from Linux are not loaded by Laravel. For instance, if I place:
'test' => 'testing123',
within the config/app.php
and do a
sudo php artisan config:cache
and employ Tinker
config('app.test');
=> "testing123"
So that seems to work. However, if I place the following
'test' => env('DB_PORT'),
and do a
sudo php artisan config:cache
and test this with tinker:
config('app.test');
=> null
But when I am in the console and use:
env|grep DB_PORT
I see the right value for the DB_PORT key. I am supplying these in AWS frontend, these properties are then passed in the application as environment properties.
Anyone any idea why these are not imported/loaded correctly?
php artisan config:clear
Or you can just manually delete bootstrap/config.php, which is what artisan does after all.
See: vendor\laravel\framework\src\Illuminate\Foundation\Console\ConfigClearCommand.php
We're currently running two laravel applications on the same dedicated server. Each application utilizes laravel's queueing system for background jobs and notifications. Each uses redis for the driver. Neither define any specific queues, they are both using the default. Our supervisor .conf is as follows:
[program:site-one-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/siteone.com/artisan queue:work --sleep=5 --tries=1
autostart=true
autorestart=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/siteone.com/storage/logs/worker.log
[program:site-two-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/sitetwo.com/artisan queue:work --sleep=5 --tries=1
autostart=true
autorestart=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/sitetwo.com/storage/logs/worker.log
Everything worked as expected before adding the configuration for the second site. After adding it, we were testing and noticed that when invoking an event on sitetwo.com that triggered a notification to be sent to the queue, that the email addresses which should have received the notifications did not, and instead they were sent to two email addresses that only exist within the database for siteone.com!
Everything seems to function as expected as long as only one of the above supervisor jobs is running.
Is there somehow a conflict between the two different applications using the same queue name for processing? Did I botch the supervisor config? Is there something else that I'm missing here?
The name of the class is all Laravel cares about when reading the queue. So if you have 2 sites dispatching the job App\Jobs\CoolEmailSender, then whichever application picks it up first is going to process it, regardless of which invoked it.
I can think of 2 things here:
Multiple redis-instances
or
unique queue names passed to --queue
I just changed APP_ENV and APP_NAME into .env file and it worked for me.
For Example:
First .env: APP_ENV=local APP_NAME = localapp
Second .env: APP_ENV=staging APP_NAME=stagingapp
Maybe late but did you try to modify the queue config at config/queue.php
'redis' => [
'driver' => 'redis',
'connection' => 'default',
'queue' => 'project1', // 'project2'...
'retry_after' => 90,
'block_for' => null,
],
run queue with --queue=project1
Note: This answer is for those who are having multiple domains, multiple apps, and one database.
You can dispatch & listen to your job from multiple servers by specifying the queue name.
App 1
dispatch((new Job($payload))->onQueue('app1'));
php artisan queue:listen --queue=app1
App 2
dispatch((new Job($payload))->onQueue('app2'));
php artisan queue:listen --queue=app2