What is the default location of session files on an installation of Apache/PHP on Ubuntu 10.10?
The default session.save_path is set to "" which will evaluate to your system's temp directory. See this comment at https://bugs.php.net/bug.php?id=26757 stating:
The new default for save_path in upcoming releaess (sic) will be the empty string, which causes the temporary directory to be probed.
You can use sys_get_temp_dir to return the directory path used for temporary files
To find the current session save path, you can use
session_save_path() — Get and/or set the current session save path
Refer to this answer to find out what the temp path is when this function returns an empty string.
First check the value of session.save_path using ini_get('session.save_path') or phpinfo(). If that is non-empty, then it will show where the session files are saved. In many scenarios it is empty by default, in which case read on:
On Ubuntu or Debian machines, if session.save_path is not set, then session files are saved in /var/lib/php5.
On RHEL and CentOS systems, if session.save_path is not set, session files will be saved in /var/lib/php/session
I think that if you compile PHP from source, then when session.save_path is not set, session files will be saved in /tmp (I have not tested this myself though).
If unsure of compiled default for session.save_path, look at the pertinent php.ini.
Normally, this will show the commented out default value.
Ubuntu/Debian old/new php.ini locations:
Older php5 with Apache: /etc/php5/apache2/php.ini
Older php5 with NGINX+FPM: /etc/php5/fpm/php.ini
Ubuntu 16+ with Apache: /etc/php/*/apache2/php.ini *
Ubuntu 16+ with NGINX+FPM - /etc/php/*/fpm/php.ini *
* /*/ = the current PHP version(s) installed on system.
To show the PHP version in use under Apache:
$ a2query -m | grep "php" | grep -Eo "[0-9]+\.[0-9]+"
7.3
Since PHP 7.3 is the version running for this example, you would use that for the php.ini:
$ grep "session.save_path" /etc/php/7.3/apache2/php.ini
;session.save_path = "/var/lib/php/sessions"
Or, combined one-liner:
$ APACHEPHPVER=$(a2query -m | grep "php" | grep -Eo "[0-9]+\.[0-9]+") \ && grep ";session.save_path" /etc/php/${APACHEPHPVER}/apache2/php.ini
Result:
;session.save_path = "/var/lib/php/sessions"
Or, use PHP itself to grab the value using the "cli" environment (see NOTE below):
$ php -r 'echo session_save_path() . "\n";'
/var/lib/php/sessions
$
These will also work:
php -i | grep session.save_path
php -r 'echo phpinfo();' | grep session.save_path
NOTE:
The 'cli' (command line) version of php.ini normally has the same default values as the Apache2/FPM versions (at least as far as the session.save_path). You could also use a similar command to echo the web server's current PHP module settings to a webpage and use wget/curl to grab the info. There are many posts regarding phpinfo() use in this regard. But, it is quicker to just use the PHP interface or grep for it in the correct php.ini to show it's default value.
EDIT: Per #aesede comment -> Added php -i. Thanks
Another common default location besides /tmp/ is /var/lib/php5/
I had the same trouble finding out the correct path for sessions on a Mac. All in all, I found out that the CLI PHP has a different temporary directory than the Apache module: Apache used /var/tmp, while CLI used something like /var/folders/kf/hk_dyn7s2z9bh7y_j59cmb3m0000gn/T. But both ways, sys_get_temp_dir() got me the right path when session.save_path is empty. Using PHP 5.5.4.
Non of the above worked for me using the IUS repo for CentOS 7 with PHP 7.2:
php -v
> PHP 7.2.30 (cli) (built: Apr 19 2020 00:32:29) ( NTS )
php -r 'echo session_save_path(), "\n";
>
php -r 'echo sys_get_temp_dir(), "\n";'
> /tmp
However, sessions weren't saved in the /tmp folder, but in the /var/lib/php/mod_php/session/ folder:
ls /var/lib/php/mod_php/session/
> sess_3cebqoq314pcnc2jgqiu840h0k sess_ck5dtaerol28fpctj6nutbn6fn sess_i24lgt2v2l58op5kfmj1k6qb3h sess_nek5q1alop8fkt84gliie91703
> sess_9ff74f4q5ihccnv6com2a8409t sess_dvrt9fmfuolr8bqt9efdpcbj0d sess_igdaksn26hm1s5nfvtjfb53pl7 sess_tgf5b7gkgno8kuvl966l9ce7nn
The only surefire option to find the current session.save_path value is always to check with phpinfo() in exactly the environment where you want to find out the session storage directory.
Reason: there can be all sorts of things that change session.save_path, either by overriding the php.ini value or by setting it at runtime with ini_set('session.save_path','/path/to/folder');. For example, web server management panels like ISPConfig, Plesk etc. often adapt this to give each website its own directory with session files.
I believe its in /tmp/. Check your phpinfo function though, it should say session.save_path in there somewhere.
Related
Recently I installed lamp and php-xdebug on an ubuntu 16.04 box. I noticed that now I have the following files
/etc/php/7.0/apache2/conf.d/20-xdebug.ini
/etc/php/7.0/cli/conf.d/20-xdebug.ini
/etc/php/7.0/mods-available/xdebug.ini
I was wandering what is the difference is between these files and settings in /etc/php/7.0/apache2/php.ini are affected by these.
Also in terms of best practice which of these files should be used?
If configurations are repeated in these files with different values which would take precedence?
For example if xdebug.remote_port = 9000 is set in /etc/php/7.0/apache2/php.ini and in /etc/php/7.0/mods-available/xdebug.ini it was set as xdebug.remote_port = 9001 which value would be selected?
Ubuntu is based on Debian. Debian and it's derivatives use a somewhat unique way of managing extensions for php and apache.
Of the files you have listed:
/etc/php/7.0/apache2/conf.d/20-xdebug.ini is a symlink to /etc/php/7.0/mods-available/xdebug.ini
/etc/php/7.0/cli/conf.d/20-xdebug.ini is also a symlink to /etc/php/7.0/mods-available/xdebug.ini
You can edit /etc/php/7.0/mods-available/xdebug.ini directly and changes you make will affect everywhere it is enabled.
Commands phpenmod and phpdismod are available to enable or disable PHP modules. These are like a2enmod for apache, which you can read about here. For example, turn XDebug off with sudo phpdismod xdebug. Turn it back on with sudo phpenmod xdebug. Your configuration will be preserved when you flip it on and off because your changes are always preserved in mods-available, although PHP does not look in that directory for configuration. In fact, when you "disable" the module with phpdismod, it's simply removing the symlink from the appropriate folder so that the module is not enabled in the php config.
Finally, /etc/php/7.0/apache2/php.ini is the location for system-wide config that is not a module that can be enabled or disabled.
Thus, your config changes like xdebug.remote_port = 9000 should go in /etc/php/7.0/mods-available/xdebug.ini since it's related to XDebug. Putting it in both places is a bad idea (because of the confusion it creates), but the last one to load takes precedence. This is why many of the files in the mods-available directory have numbers in the filename - so they'll load in the correct order.
Use the phpinfo() function to get more info about which config values were loaded and what ini files they were loaded from. For example:
$ php -r "phpinfo();"
or
$ php -r "phpinfo();" | grep xdebug
This depends on how PHP was compiled. Take a look at how PHP was compiled by reviewing the list of .ini files it is loading and from where they are being loaded.
From the command line, type the following and review:
$ php -i | grep .ini
Or, you can learn of this by creating a temporary PHP file and visiting it in a browser. Just be sure to name it something difficult to find, and delete it right after you're done; e.g., /info-949w30.php. Why? Because this report may leak full filesystem paths, version numbers, and other details.
<?php phpinfo();
PHP has two directives that are established when it's compiled.
--with-config-file-path=path/to/main.ini
--with-config-file-scan-dir=/scan/this/dir/for/other.ini files.
The main .ini file is loaded first, and then files in the scan-dir are loaded alphabetically after that. Which is why you see a lot of .ini files using a numeric prefix. That's an easy way to take control over the load order. Changing the name of the file in relation to others in the directory.
I have found that:
When I type the following on terminal:
php -i | grep php.ini
I get the output:
The Loaded Configuration file is # /etc/php5/cli/php.ini
However, from phpinfo(), I get to see:
The loaded ini file is # /etc/php5/apache2/php.ini
Which one of these is working right now? How is it possible to have two php.ini files ?
Depends on where you are running PHP from. If you run it from command line, it uses the cli/php.ini and apache2/php.ini when run through apache.
You are executing phpinfo() through the browser, hence you get /etc/php5/apache2/php.ini as the answer. Running php -r "phpinfo();" | grep "Loaded Configuration" from the terminal should output the CLI ini. Same function, context changes.
The advantage of this system is obviously to allow different configurations depending on the context. For a simplified example, you might want to have safe_mode on in apache but it's unnecessary in CLI mode.
Your .ini paths are actually quite unusual. Normally, the default .ini is just php.ini and CLI .ini is called php-cli.ini and they reside in the same folder.
I'm no expert on the subject but this should be the basic idea. If anyone has any corrections, I'd be happy to hear them.
I'm running a console command for symfony sudo php app/console assetic:dump and it is showing Warnings even though I specifically ignore Warnings on the php.ini for apache and for cli.
Is it using a different php.ini altogether?
Do sudo php -i for a readout of your PHP settings, including the path to php.ini.
Run the following command:
php -i | grep .ini
and you will see the full path of the php.ini used by cli.
Don't use sudo when dumping assets as the owner of the created files will be "root" and the nginx/apache user will not be able to use them.
Yes, it is probable that php used on the command line uses a different php.ini than php in apache.
Specifically in wamp server, php cli uses the php.ini in the php directory, and php as apache module uses php.ini situated in the apache/bin folder.
I have setup Eclipse 3.6.2 on Ubuntu 11.4 for AMD64 and Xdebug.
Eclipse was installed with zip download from eclipse.org.
PHP and Xdebug were setup with apt-get.
When I run the PHP script in the shell they will use the /etc/php5/php.ini file and parse additional ini files in /etc/php5/conf.d/.
When I run in Eclipse (run mode or debug mode) it will only parse php.ini and no additional ini files.
Basically, all extensions, are not loaded.
It is an intentional bug.
PDT executes php with "-n" option always. It makes additional ini files unavailable.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=339547
also https://bugs.eclipse.org/bugs/show_bug.cgi?id=347618
BTW, you'll be able to add a shell script which trims "-n" option as PHP Executable.(Preferences>PHP>PHP Executables)
For example,
#!/bin/sh
if [ $1 = "-n" ]; then
shift;
fi
/usr/bin/php $*
The answer #atlanto gives as a work around did and does still work, but recent version of Eclipse (I'm on Neon) has a fix that may work for you if you don't mind using the php.ini and conf.d set by default for the php executable.
The failing to load additional files only happens now if you put in an explicit php.ini file when defining a PHP executable. Leave this blank and check the box Use system default php.ini configurate.
Now if you use the location/php.ini that was specified as default when the executable was built, it will respect scanning of conf.d directories.
Here's how to check if your php has scanning conf.d enable and where the approriate default location is:
php -i "(command-line 'phpinfo()')" | grep "Configure Command"
You should see something like:
Configure Command => './configure' '--prefix=/usr/local/Cellar/php5/5.6.29_5'
'--localstatedir=/usr/local/var' '--sysconfdir=/usr/local/etc/php/5.6'
'--with-config-file-path=/usr/local/etc/php/5.6'
'--with-config-file-scan-dir=/usr/local/etc/php/5.6/conf.d'
'--mandir=/usr/local/Cellar/php56/5.6.29_5/share/man'
... and so on...
The items that matter are:
with-config-file-path: this where it will look for your php.ini file
with-config-file-scan-dir: this is the conf.d that will be scanned
If you still wish to choose a different in location than the default for the executable your options are:
Inline the module directives from and file in conf.d into your alternate php.ini
Rebuild php and set the above options to your new location as default
Use the wrapper script #atlanto indicates
I have found that:
When I type the following on terminal:
php -i | grep php.ini
I get the output:
The Loaded Configuration file is # /etc/php5/cli/php.ini
However, from phpinfo(), I get to see:
The loaded ini file is # /etc/php5/apache2/php.ini
Which one of these is working right now? How is it possible to have two php.ini files ?
Depends on where you are running PHP from. If you run it from command line, it uses the cli/php.ini and apache2/php.ini when run through apache.
You are executing phpinfo() through the browser, hence you get /etc/php5/apache2/php.ini as the answer. Running php -r "phpinfo();" | grep "Loaded Configuration" from the terminal should output the CLI ini. Same function, context changes.
The advantage of this system is obviously to allow different configurations depending on the context. For a simplified example, you might want to have safe_mode on in apache but it's unnecessary in CLI mode.
Your .ini paths are actually quite unusual. Normally, the default .ini is just php.ini and CLI .ini is called php-cli.ini and they reside in the same folder.
I'm no expert on the subject but this should be the basic idea. If anyone has any corrections, I'd be happy to hear them.