Site loading issue possibly caused by missing PHP FPM Reloading / Artisan Migrate and Deployer 7

[jasperf]

I recall reading somewhere that we no longer need to reload PHP FPM on deployment with Deployer 7. Or perhaps we never did. But we do seem to have issues with things to work properly sometimes post deployment now with data not loading properly for sites. I also red artisan migrate is part of prepare now.. So here two questions really

PHP FPM Reload with Laravel Forge and Deployer 7

I read on https://stackoverflow.com/questions/37318795/why-does-envoyer-need-to-restart-php-fpm-when-deploying

It's because your new deployment is created in a different directory to the one currently being served by php. The release is symlinked from the directory specified in the nginx config.

So question, would it still be needed to reload PHP FPM on our Laravel Vue up using:

import:
  - recipe/laravel.php
  - contrib/php-fpm.php
  - contrib/npm.php

config:
  application: 'site-app'
  remote_user: forge
  deploy_path: '~/{{hostname}}'
  repository: 'git@github.com:site/site-app.git'
  php_fpm_version: '8.0'
  keep_releases: '10'
  shared_files: 
    - '.env'
    - '.transip_private_key'
    - 'storage/app/exact.api.json'
  shared_dirs:
    - 'bootstrap/cache'
    - 'public/uploads'
    - 'public/published'
    - 'storage/framework/cache'
    - 'storage/framework/sessions'
    - 'storage/framework/views'
    - 'storage/logs'
    - 'storage/tls'
    - 'storage/app/public'
    - 'storage/app/modules'
  writable_dirs:
    - 'public/uploads'
    - 'public/published'
    - 'storage/framework/cache/data'
    - 'storage/logs'
    - 'storage/tls'
    - 'storage/app/public'
    - 'storage/app/modules'

hosts:
  prod:
    hostname: 'site.com'
  staging:
    hostname: 'staging.site.com'

tasks:
  deploy:
    - deploy:prepare
    - deploy:vendors
    - artisan:storage:link
    - artisan:view:cache
    - artisan:config:cache
    - artisan:optimize
    - artisan:migrate
    - artisan:queue:restart    
    - artisan:horizon:terminate
    - deploy:publish

after:
  deploy:failed: deploy:unlock

At https://github.com/deployphp/deployer/blob/master/contrib/php-fpm.php you mention

## Installing
:::caution
Do **not** reload php-fpm. Some user requests could fail or not complete in the
process of reloading.
Instead, configure your server [properly](https://ï.at/avoid-php-fpm-reloading). If you're using Deployer's provision
recipe, it's already configured the right way and no php-fpm reload is needed.
:::

so would think not it a good idea.. but then wonder why we do not get JSON data using Laravel from the database. And that would get me back to the SO comment using Envoyer on Laravel Forge setups with Nginx to load the new symlink from Nginx root /home/forge/site.com/current/public;

Reload PHP FPM with yaml

Seems like we do need to reload PHP FPM in our Laravel Forge case and that makes me get to another more specific question. How would I do a PHP FPM Reload with yaml to test the need to load the new path/symlink?

We had this before:

task('reload:php-fpm', function () {
run('sudo /etc/init.d/php7.4-fpm restart');
});
...

after('deploy', 'reload:php-fpm');
after('rollback', 'reload:php-fpm');

and server allows passwordless reload of PHP FPM..

but how to set this in yaml for php8.0?

PHP Artisan Migrate as separate task

Two, do we need artisan:migrate in Deployer 7 or is that now part of prepare as I also recall having read somewhere..

[jasperf]

Do need to reload PHP FPM it seems but

after:
  deploy: reload:php-fpm
  deploy:failed: deploy:unlock

did not work when I tested using dep tree deploy and neither did

after:
  deploy:php-fpm:reload
  deploy:failed: deploy:unlock

nor

after:
  php-fpm:reload
  deploy:failed: deploy:unlock

[jasperf]

This:

after:
  deploy:symlink: php-fpm:reload
  deploy:failed: deploy:unlock

with updated after deployment PHP FPM reload command works in the test dep tree deploy:

dep tree deploy
Using /Users/me/code/site.com/site.com/vendor/bin/dep
The task-tree for deploy:
└── deploy
    ├── deploy:prepare
    │   ├── deploy:info
    │   ├── deploy:setup
    │   ├── deploy:lock
    │   ├── deploy:release
    │   ├── deploy:update_code
    │   ├── deploy:check_env  // before deploy:shared
    │   ├── deploy:shared
    │   └── deploy:writable
    ├── deploy:vendors
    ├── deploy:regenerate_key  // after deploy:vendors
    ├── artisan:storage:link
    ├── artisan:view:cache
    ├── artisan:config:cache
    ├── artisan:optimize
    ├── artisan:migrate
    ├── artisan:queue:restart
    ├── artisan:horizon:terminate
    └── deploy:publish
        ├── deploy:symlink
        ├── php-fpm:reload  // after deploy:symlink
        ├── deploy:unlock
        ├── deploy:cleanup
        └── deploy:success

[jasperf]

Thanks for that @lorisleiva . Yes, I decided to keep on using a PHP FPM reload for now, but might move to provisioning via Deployer as well. Or Ploi.io if they do this better somehow.. But if I do via Deployer I wonder if I need or should use Forge still. I guess not as Deployer does it its way.

[antonmedv]

Deployer’s provision recipe basically do the same as Forge. So no need to.

[lorisleiva]

Oh, wait so that means even with Forge, we shouldn't need to reload PHP FPM by default?

I'm confused because reloading PHP FPM is still on their default deploy script.

[jasperf]

For loading new deployment via symlink we still need a reload I believe . That is besides reload needing when using OPCache .

I assume that Deployer does the PHP FPM realpath loading. Have not checked the provisioning script yet.

[antonmedv]

Oh, wait so that means even with Forge, we shouldn't need to reload PHP FPM by default?

Yes, if nginx configured correctly. I will try to find some time today to write doc about it in Deployer.

I assume that Deployer does the PHP FPM realpath loading.

Yes, current symlink resolved to realpath.