I am new to PHP, Symfony and Redis and have a query around integration of Redis with a symfony project deployed on Apache httpd as the server for session management.
The below is the software's and their versions that I am using
OS - CentOS 7
Redis - 3.2.4 - Built Redis from the source code
Symfony - 2.8
PHP 7 - Installed the below packages
php70w
php70w-cli
php70w-common
php70w-fpm
php70w-opcache
php70w-pdo
php70w-pear
php70w-process
php70w-xml
php70w-pecl-redis
I have made the below entries in php.ini file
session.save_handler = redis
session.save_path = "tcp://<<ip address of redis server>>:6379"
session.auto_start = 1
What is confusing me is do I have to write session management through my symfony code using phpredis client or should it happen automatically.
Please let me know which method I should use to go further as the redis server does not seem to be populated with the session.
All the above configurations have been done by referring the below link and has been made centos specific
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
Thanks.
You have to change default session handler. To omit Symfony session handler and use PHP instead set the handler_id option to null in settings.yml:
framework:
session:
handler_id: null
http://symfony.com/doc/current/reference/configuration/framework.html#handler-id
The problem was with Apache server on which I had hosted my Symfony application.
Apache had mod_php enabled and in Apache's conf.d folder I had a file named php.conf. It had properties like the ones below
php_value session.save_handler "files"
php_value session.save_path "/var/lib/php/session"
php_value soap.wsdl_cache_dir "/var/lib/php/wsdlcache"
I commented the above values and added the below and it worked. It looks like the configuration values present in php.conf in Apache's conf.d folder overrides the value of the same properties present in php.ini.
php_value session.save_handler "redis"
php_value session.save_path "tcp://<ip address of redis>:6379"
After making the below changes I have been able to see my php sessions on my redis server.
Thanks.
Related
I need to change PHP max_input_vars variable but after change in php.ini and server restart phpinfo shows old value all the time. This is what i do:
in phpinfo() i've got
...
Loaded Configuration File /etc/php.ini
...
max_input_vars 1000
from server CL I've edit /etc/php.ini and uncomment line with max_input_vars it looks like this:
...
max_input_vars = 5000
...
after this changes and restarting web server
systemctl restart httpd
phpinfo still shows max_input_vars as 1000
It looks like php use some other php.ini or values are overwritten because with other settings like max_execution_time is the same.
If i'm doing it wrong way? Is this possible that phpinfo shows different configuration file than the one used?
phpinfo output:
As you're using PHP-FPM, you need to check it's configs for overrides, typically in /etc/php-fpm/*.conf.
php_admin_value[max_input_vars] = XXX
After validating there are no overrides that affect your settings, restart the php-fpm service and as a best-practice also Apache.
systemctl restart php-fpm httpd
Restarting the PHP-FPM service is required because Apache passes requests to the running PHP instance(s) loaded into memory from the PHP-FPM service. As PHP is already loaded into memory by PHP-FPM, the PHP-FPM service needs to be restarted for PHP configuration changes to be applied.
Apache prior to PHP-FPM typically relied on starting the PHP process using the Apache mod_php, thereby requiring the restarting of the Apache service for configuration changes to be applied immediately, or until mod_php reloaded the PHP instance.
Based on your configuration, you should add additional PHP config settings to /etc/php.d/zzz-custom.ini instead of /etc/php.ini. PHP will load the config files in alphabetical order, resulting in the zzz-custom.ini file being loaded last and be used as the final values of the PHP settings.
Using the /etc/php.d/zzz-custom.ini file will also prevent the loss of your custom php.ini settings and the need to make extensive changes to the default /etc/php.ini file when updating PHP versions.
However, /etc/php-fpm/*.conf settings will take precedent over any /etc/php.d/*.ini configs.
first: Method is edit the PHP. ini file
Locate your PHP. ini file. ...
If you find your existing PHP. ini, open the file and locate the following line of code (xx represents a number): max_input_vars = xx ; And set it to your desired limit. ...
If you created your own PHP. ...
Save your changes, and reboot your localhost or your server.
I have got this error PHP Fatal error: Directive 'safe_mode' is no longer available in PHP in Unknown on line 0 when I have updated my hosting PHP version from 5.6 to 7.2
how can I solve this problem or I must contact my hosting provider ?!
here is my php.ini setting file found in my mean path
; cPanel-generated PHP ini directives, do not edit
; Manual editing of this file may result in unexpected behavior.
; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
; For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
magic_quotes_gpc = Off;
register_globals = Off;
default_charset = UTF-8;
memory_limit = 64M
max_execution_time = 36000
upload_max_filesize = 999M
safe_mode = On;
mysql.connect_timeout = 20;
session.auto_start = Off;
session.use_only_cookies = On;
session.use_cookies = On;
session.use_trans_sid = Off;
session.cookie_httponly = On;
session.gc_maxlifetime = 3600
allow_url_fopen = On
display_errors = On
;error_reporting = E_ALL;
allow_url_include = On
enable_dl = On
file_uploads = On
max_input_time = 60
max_input_vars = 1000
post_max_size = 8M
session.save_path = "/var/cpanel/php/sessions/ea3"
zlib.output_compression = Off
First, you should read up on safe_mode. In the docs, will see that:
Warning: This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
Second, you can get the error to go away by removing this line:
safe_mode = On;
NOTE: You must be certain to find the correct INI file. Some operating systems or methods of installing PHP will have a separate php.ini file for the web server and Command Line Interface (CLI). For example, on my ubuntu workstation, I have one for apache and one for CLI:
/etc/php5/cli/php.ini
/etc/php5/apache2/php.ini
To find out what INI file you should edit, I suggest looking at the output of phpinfo() and looking at the value for Loaded Configuration File. To do that on a web server, use this file:
<?php
phpinfo();
If you want to find out where the php.ini file is for CLI scripts, you can use this command:
php -i | grep "Loaded Configuration File"
If you are make changes to the ini file for your web server, you'll need to restart the web server for this change to take effect. On Ubuntu or other debian-based distros, you might do that with a command like so:
sudo service apache2 restart
You may need to tweak that command, depending on distro, distro version, apache version, etc. I believe that for CentOS or Red Hat-based distros, one of these should work:
sudo service httpd restart
sudo apachectl restart
NOTE: If your machine is configured to use php-fpm for handling PHP requests, then things work differently for your web server. Your system will maintain a process pool of PHP processes entirely separate from your web server. You will need to restart the PHP process pool. The command to accomplish that varies widely depending on the distro and your version of PHP. Check this page for your distro and see if you can find one that works.
For CLI invocations of PHP, the changes should take effect each time you run a new php script. You shouldn't have to restart anything for new commands to see the changes you made. If you have some long-running PHP script for some reason (very unusual) then you'd need to halt that process and re-invoke it after making your INI changes.
EDIT: I'd also point out that your INI file very clearly states you might get weird behavior on your CPANEL system. Make sure you follow its instructions:
; cPanel-generated PHP ini directives, do not edit
; Manual editing of this file may result in unexpected behavior.
; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
; For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
although the path /mnt/my-proj/app/../var/sessions/dev is accessible for both the normal user and www-data I get the following message:
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/mnt/op-accounting2/app/../var/sessions/dev)
I get the message above only in dev, but not in prod.
/mnt/my-proj/app/../var/sessions/dev and /mnt/my-proj/app/../var/sessions/prod have the same pemissions: 777.
The path above is mounted as following:
# mount -t vboxsf -o uid=1000,gid=33,umask=000 my-proj /mnt/my-proj;
What am I doing wrong?
I've read the following posts, but could find no solution for me:
PHP session handling errors
https://github.com/NewEraCracker/suhosin-patches/issues/3
PHP7 + Symfony 2.8, Failed to write session data
I'm using Vagrant 1.8.1 on Windows 8.1 Enterprice (64Bit) and ubuntu-xenial 16.04 in Vagrant. The provider is VirtualBox 5.0.20. The settings are mostly default ones. The path above is shared using VirtualBox GUI with full access.
Kind regards,
Juri
SOLVED! :-)
Setting
save_path: "/var/lib/php/sessions"
in /mnt/my-proj/app/config/config.yml solved the problem. Any adjusting of ini-Files in /etc/php/7.0/ wasn't neccessary (those files have still default values only).
But I wander why didn't I get that error message in prod?
You can just edit the configured file.
vi /etc/php/7.2/fpm/pool.d/www.conf
Then change the owner role for PHP from www-data to vagrant
user = vagrant
group = vagrant
In addition to the previous answer from Juri Sinitson, it also solved me tweaking the VM instead of tweaking the project base.
Adding to my Vagrant bash root provisioner this line:
sed -i "s/www-data/vagrant/g" /etc/apache2/envvars
service apache2 restart
Makes the apache run as vagrant. This confers apache more power on the shared directory as it appears to the filesystem that it is the user vagrant and not the user www-data who happens to be touching there.
Maybe this is 'apparmor' related or so.
I am attempting to install Drupal 7 on my local debian jessie machine, and it is telling me the following:
Multibyte string input conversion in PHP is active and must be
disabled. Check the php.ini mbstring.http_input setting. Please refer
to the PHP mbstring documentation for more information.
Ok, so I head over to the php documentation linked in that message and it provides me with a lot of (helpful, I am sure) information not at all related to disabling "Multibyte string input conversion". If it's there, I didn't find it.
I googled and came up with a thread on drupal.org, which claims:
Since Drupal made it mandatory to disable mbstring.http_input and its
'relatives', a lot complaints regarding Drupal installation was raised
everywhere in cyberspace. It's not a problem if you own your own
server, and there's a lot of workaround.
And provides a link to a page that I add the following to my .htaccess file:
php_value mbstring.http_input pass
php_value mbstring.http_output pass
So I had a look in my .htaccess file and found this:
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_flag magic_quotes_gpc off
php_flag magic_quotes_sybase off
php_flag register_globals off
php_flag session.auto_start off
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_flag mbstring.encoding_translation off
</IfModule>
Right, so now what?
EDIT: Just added the following line to my php.ini file:
mbstring.http_input = pass ; No conversion.
and ran service apache2 reload. No effect.
Added the following to my php.ini file:
mbstring.http_input = pass ;
mbstring.http_output = pass ;
then I ran
sudo service apache2 reload
And then I could install drupal manually, however, if I try using drush I still get the error, so this is really just half a solution...
Instead you can edit your site's .htaccess file or settings.php file to do so.
This way there will not be any conflict between your site and your drush configuration. And in case you changed your server's php version in the future, you don't have to re-do the same changes to the new php version's php.ini file.
Via .htaccess:
php_value mbstring.http_input pass
php_value mbstring.http_output pass
Or via settings.php:
ini_set('mbstring.http_input', 'pass');
ini_set('mbstring.http_output', 'pass');
To disable mbstring function overloading without disabling mbstring, you have to use
mbstring.func_overload = 0
This can be set in the php.ini file, and if not set there, in the vhost setting or .htaccess.
If it does not work, try looking for an mbstring.ini file, for example in /etc/php.d/mbstring.ini. This gets loaded after php.ini, and will override any value set there.
You may also need to add the following, however this is already set in Drupal's htaccess file, so if this file is being loaded correctly there should be no change.
php_value mbstring.http_input pass
php_value mbstring.http_output pass
For me, installing php-mbstring module helped to resolve this error.
the same error here with the installation of a drupal demo
but I realised that the site has no .htaccess file
I copied one into the site
and the problem disappeared
Uncomment extension=php_mbstring.dll in php.ini file and restart apache
Drupal is asking you to enable the mbstring (multibyte string), but your default php settings has this option disabled. If you can change your php.ini file to enable this, then your problem will be fixed, but sometimes we don't have access to that file.
Instead, we can set drupal to enable this option only for this particular site. On your sites/default/settings.php file (or the respective copy you may be using), add this:
ini_set('mbstring.http_input', 'pass');
ini_set('mbstring.http_output', 'pass');
and reload your php
This will set the mbstring option for this particular drupal site. If this still fails, it may be possible that your server's php does not have mbstring installed at all. Run phpinfo() in your browser and search for a mbstring section. If you don't find it at all, then you need to install it or ask a server administrator to do it for you
As the title state for some reason my Symfony 2.5 Application is calling the php garbage collector even when all of my php.ini files have:
session.gc_probability = 0
Does anyone know how to prevent this from happening?
Error message im getting:
Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php5)
failed: Permission denied (13) in /<path-to-my-site>/var/cache/dev/classes.php line 432
FROM PHPINFO():
Directive Local Value Master Value
session.gc_divisor 1000 1000
session.gc_maxlifetime 86400 86400
session.gc_probability 0 0
I know that i can just give the www-data user permission to the /var/lib/php5 folder or change the session.save_path to somewhere that the www-data user has access to already but i want to know why this process is even getting called when it should be disabled.
I found it, I guess the latest version of symfony is overwriting this by default when using the app_dev.php. The Symfony FrameworkBundle is setting the session.gc_probability = 1.
As of Symfony 3
However, some operating systems do their own session handling and set the session.gc_probability variable to 0 to stop PHP doing garbage collection. That's why Symfony now overwrites this value to 1.
If you wish to use the original value set in your php.ini, add the following configuration:
# config.yml
framework:
session:
gc_probability: null
https://symfony.com/doc/current/components/http_foundation/session_configuration.html#configuring-garbage-collection
Previous 2.x versions
To change this add the following to your config.yml
framework:
session:
gc_probability: 0
Then clear the dev cache
php app/console cache:clear
This is where it shows the gc_probability defaulted to 1. Why they dont just read from the php.ini settings im not sure.
http://symfony.com/doc/2.5/reference/configuration/framework.html#gc-probability
You can set path for sessions manually. See Symfony doc on sessions directory.
# app/config/config.yml
framework:
session:
handler_id: session.handler.native_file
save_path: '%kernel.root_dir%/sessions'