I meet a problem with php-fpm when deploying new code to the webserver.
I have nginx + php-fpm + apc to serve my site. for code deployment, I use git to pull code form git repository.
The problem is : when I git pull the new code to deploy code update to web server, php-fpm does not reflect the update, still serve the code before pull. I have to restart php-fpm, then the updated code is served.
This is very inconvenient for deployment. I googled around but does not find any hint about the reason behind.
Can anyone tell me why and is their any way to avoid restart?
This doesn't actually sound like an FPM problem but an APC related issue. I believe your APC is caching your content and it wouldn't be reflected until FPM was restarted.
This indeed does sound like a php-fpm problem. You have to reload php-fpm in order to update what php files are being served. To do this run "service php-fpm reload" or "service php7.0-fpm reload" for php7. This basically clears its code cache and refreshes to display the newest state of your code.
Related
Is there a way to find why my alert manager configurations are not being applied?
from the doc, the reason for that is that the file is not valid.
Alertmanager can reload its configuration at runtime. If the new configuration is not well-formed, the changes will not be applied and an error is logged. A configuration reload is triggered by sending a SIGHUP to the processor sending an HTTP POST request to the /-/reload endpoint.
Blockquote
I am trying to find a way to test the validity of my alertmanager.yaml
I came through the amtool git repo then it takes me through installing the alert manager itself where amtool is included inside.
Ok, I did that and I got the amtool.exe downloaded inside the alert manager package.
I added my file in the config folder that is supposed to be scanned by the tool. But I didn't get an answer from it, it keeps shutting its console screen without showing any log.
Second,
I have installed the Prometheus stack Helm chart on my k8s cluster from the Prometheus stack community git repo, how do I find the amtool inside?
No code sample it is not a code issue.
Thanks everyone.
I've developed a sylius based site on a local server. I want to deploy it in production on my OVH server.
In the Sylius Sylius Cookbook, I did not find any particular procedure. So I followed the normal procedure.
Upload my code to the production server with a "git clone" of my git repository
Install my vendor dependencies "php composer install"But this step does not work because it never ends. At the end, I always have something like this:
Executing script cache:clear
[Symfony\Component\Process\Exception\ProcessTimedOutException]
The process "'/usr/local/php7.3/bin/php' '--php-ini=/usr/local/php7.3/etc/php.ini' './bin/console' --ansi cache:clear" exceeded the timeout of 20000 seconds.
I even tried "composer clearcache" before. It hasn't changed anything.
I am now trying "COMPOSER_PROCESS_TIMEOUT = 50,000". The "composer install" was sent 12 hours ago and is still not finished ...
Has anyone ever had this problem or know how to find a solution?
Is there a special step to do when working with sylius?
Because I really don't know what to do.
UPDATE:
My main lead at the moment is that the problem would come from sylius because I am trying to create a new install of sylius with the symfony 4 structure like this
composer create-project sylius/sylius-standard
Same result:
Executing script cache:clear
[Symfony\Component\Process\Exception\ProcessTimedOutException] The
process "'/usr/local/php7.3/bin/php'
'--php-ini=/usr/local/php7.3/etc/php.ini' './bin/console' --ansi
cache:clear" exceeded the timeout of 20000 seconds.
I tried to run composer create-project with the --no-scripts flag and run php bin/console cache:clear separately after that. The bug reappears with the second command.
You should first check that you are setting permissions right for your var folder, as per symfony install instructions.
You might also just be running out of resources on that server. Had the same issue on my last 1.7 project. The problem came from the cache:clear's warmup (probably because sylius has tons of dependencies and I added a bunch more). You might wanna try editing the composer.json "scripts" to:
"scripts": {
"auto-scripts": {
"cache:clear --no-warmup": "symfony-cmd",
"assets:install %PUBLIC_DIR%": "symfony-cmd"
},
Or, as you did per your update, run the install with the --no-script flag followed by bin/console cache:clear --no-warmup (do make sure you are installing the assets after that).
Cache will then be generated on your first visit to the website instead of being generated thru warmup.
This is a problem not just with the install, you'll have to use this workaround each time you wanna clear cache. My project is in production and working well using this, just gotta remember to visit the website once you did so that a random user doesn't have longer loading because the cache hasn't been generated yet.
We are attempting to deploy new PHP code via Capistrano while running Opcache.
Capistrano creates a new deploy directory each time you deploy, then adjusts a symlink so that the webserver points to the new directory. Because Opcache caches by the real path of the file, that means that the newly deployed version of a site is cached completely separately from the old.
The problem we are running into is that Opcache runs out memory because each new deploy causes the full code base to be cached, and old code is never evicted. We could call opcache_reset(), but when the cache is reset, we briefly get 500 errors when the caches stampede. (We would also have the same errors if we tried to launch a new deploy without warming up the cache.)
Is there a better way to handle this? Some way to launch the new code while not filling up opcache until it runs out of memory (or empties itself because it has too many files) that allows us to avoid calling opcache_reset() on the live site? We are using (or trying to transition to, anyway) Nginx as our web server with PHP-FPM handling the PHP requests.
An option would be to call opcache_invalidate for each of the files in the old version of the site at the end of the deployment. You could prevent cache stampede by including the file following the invalidation.
A second option would be to setup fpm to have multiple pools, and to restart them one by one (they'll start with a clean opcache). You'll somewhat prevent the cache stampede only one server will have a clean cache at any given time, and the application will stay up because nginx will be able to balance the load on the various pool.
Another option is to delete the old versions of the script, so that opcache clears them from the cache once the revalidate_freq has passed, forcing it to load the new files from the filesystem.
I have deployed my application on WAS 8 as debug. The server status is [Debugging, Synchronized]. When I put breakpoints and start the application, it doesn't stop at the breakpoints. I don't see the debugger thread start either.
I am using RAD 8.0.4 and JDK 1.6.0_31. I have tried cleaning the project and re-deploying but it still doesn't work.
I was able to get it working via a complete clean install of my app. Then removing it from the server via add remove. Clearing cache from the websphere/profiles/myprofile directory. and clearing all bits of my app from the profiles folder via a search for its containing file aka (myproject-folder). Then re-installed the app via add remove on the server and it worked for me.
Best guess I have is something was actually out of sync even though the server though everything was A okay.
WebSphere is a PITA and seems to get out of state too easily.
I'd restart the server and perhaps do a clean on the server (right click on the server, click "Clean...". If that doesn't work, you'll have to take a careful look at the location of your break points. They might not be on code that's getting executed. Place a break point further upstream if necessary, follow it down just to confirm the flow.
I generated a full app from the command console:
mojo generate app MyApp
After that i started the dev server:
morbo myapp
I changed some code, even changed the name of the default controller, but i can not see any changes in the browser, only if i restart the morbo server works.
This is reallly annoying for developing.
How to get rid of this caching behaviour?
UPDATE: i noticed if i use hypnotoad instead morbo, works and updates changes properly, so the problem is morbo.
I've never had this problem before but there is watch().
http://mojolicio.us/perldoc/Mojo/Server/Morbo#watch
Maybe if you explicitly tell the server where to look for
changed files it will work. Or, perhaps that can help you
find where the problem is.
On an aditional note, if you want to have live updates directly using morbo+fullapp you should cd to the app's folder then run
$ morbo script/myapp
It would then work properly.