Compile error after cache clear and warmup #25654
Comments
|
Would you be able to try with 3.4@dev? I think this is fixed already. |
|
So the problem probably lies in the fact that the supervisor processes still look at the old container folder (in memory problem). |
|
So I had the same error showing up when deploying on prod since I updated to 3.4. I took the time to investigate this problem and found how to reproduce it. Use this command on a fresh Symfony standard edition : <?php
namespace AppBundle\Command;
use Symfony\Bundle\FrameworkBundle\Command\ContainerAwareCommand;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Style\SymfonyStyle;
use Symfony\Component\Process\Process;
class TempCommand extends ContainerAwareCommand
{
protected function configure()
{
$this
->setName('app:temp');
}
/**
* @param InputInterface $input
* @param OutputInterface $output
*
* @return int
*/
protected function execute(InputInterface $input, OutputInterface $output)
{
$process = new Process('php bin/console cache:clear');
$process->run();
return 0;
}
}Works fine on 3.3, fails on 3.4.
Also I can confirm you that using the same fix as in #24908 is working here. If you have |
|
@nicolas-grekas You were right, I just tested it on 3.4@dev and the error is gone. @coudenysj IMHO, this issue can be closed. |
|
I'll have a look at 3.4@dev. Currently having the issue in v3.4.2 (29961b6). |
|
I upgraded (29961b6...1b36d03), but still have the issue. It is probably due to the fact that processes still look at the old container. I'll look in to it later and reopen this issue if it is a problem in Symfony. |
|
I still have the problem too after upgrading to 3.4.3. My reproducer works but not my real code. |
|
Thanks to @polem, we found that we had effectively processes running with supervisor which used the old container |
|
@fancyweb @coudenysj could you please confirm that your case is fixed by #25733? |
…fresh again (nicolas-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [HttpKernel] Fix compile error when a legacy container is fresh again | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #25654 | License | MIT | Doc PR | - Noticed by @jpauli again: when reverting some configuration changes ends up generating the same container as the previously legacy one, the legacy flag should be removed. Commits ------- 8c3eadb [HttpKernel] Fix compile error when a legacy container is fresh again
|
It doesn't fix it for me but I guess the problem could also be in the way I deploy or in my setup. sudo ./stop_sv_services.sh
cd /path/to/my/site/dir
git pull origin prod
composer install --no-dev --optimize-autoloader
php bin/console doctrine:migrations:migrate -n
php bin/console assetic:dump
php bin/console doctrine:cache:clear-metadata
php bin/console doctrine:cache:clear-result
php bin/console doctrine:cache:clear-query
php bin/console cache:clear
php bin/console cache:warmup
sudo ./start_sv_services.shI use runsv to run commands continually. The |
|
This is exactly where the problem lies. If you have long running processes, you will hit this error. The processes have a path to the old container in memory, which doesn't exist anymore after a cache rebuild. I try to solve it by stopping the long running processes (Symfony commands) before I rebuild the cache, and start them again afterwards. This still sometimes gives me an error when someone clears the cache directly via the commands, so this change is kind of annoying. |
|
There is no fix to this on Symfony's side: if the underlying code changes, you must restart your long running processes. No way around. |
|
(it could happen with any class really) |
|
The processes are restarted (stopped before cache:clear and then started again). Also why the error doesn't appear when the script is directly executed ? |
|
Just as a clarification for users having the same issue: The problem lies in the fact that Symfony changes the class name of the generated container (and thus changes the filename). When you have long running scripts, they have the old container file open (in memory), but it does not exist anymore. You could check this with The process keeps running, until you ask it to do something, and then it crashes (because it tries to load the container file, which is gone). In the older versions of Symfony, the container file was just loaded again (because the filename was the same) and everything worked fine. Something to keep in mind. |
Actually, it was not loaded again: the old file was still loaded and used for the whole life of the process. |
|
@fancyweb btw your snippet is strange: |
This is related to #24885.
I run a couple commands during deployment, clear cache, warm cache, other commands, and always get a Fatal Compile Error after the cache warmup:
The text was updated successfully, but these errors were encountered: