I've been combing through my /etc/php/7.0/apache2/php.ini and /etc/apache2/apache2.conf files while trying to set up a specific error log file to dump all the errors in.
Using phpinfo(); I see that /var/www/html/error_log is being used for error_log which is what I want. I set this up in /etc/php/7.0/apache2/php.ini already.
However, php errors are still being placed in /var/log/apache2/error.log
I tried restarting Apache using sudo service apache2 restart yet the issue persists.
Do you have any suggestions for how I can fix this? Let me know if you'd like more information.
PHP can be used and configured by two ways.
First of all the php.ini is taken and all those settings are used in CLI mode, so when you call a script from terminal or console.
Second way is a webserver, in your case apache. This uses either mod_php or php-fpm. Apache is controlled by custom config files which you will find in /etc/apache2/sites-enabled. Depending on how you configure your hostnames, ideally one file per virtual host, those settings will override that from the php.ini. One of commonly overritten values is log file and the access file.
Changing settings in a apache config require a service restart, because apache keeps them all in memory for performance.
Related
On a fresh install of Fedora 28 running PHP 7.2.14 I am experiencing a strange issue where short_open_tag = On in the main php.ini is being ignored. I have verified that there is only one instance of the flag in only the main php.ini (/etc/php.ini). I have tried setting the flag on in .htaccess with php_value short_open_tag 1. I have restarted Apache after each change. But when I verify with phpinfo() the flag is always set to Off. Has this flag been finally deprecated and the change is simply not reflected in the PHP change log (http://php.net/ChangeLog-7.php)? Looking through the PHP source (which I am no expert at) does not suggest an override so I am at a loss for explanation. Any insight would be appreciated.
I will first note that this question looks like a duplicate of this one. On the off chance it's not, here's my best answer.
The PHP documentation has a page on the opening tags which says:
PHP also allows for short open tag <? (which is discouraged since it is only available if enabled using the short_open_tag php.ini configuration file directive, or if PHP was configured with the --enable-short-tags option).
Check phpinfo() and you may see a section entitled Configure Command which contains compilation options. See if there's an --enable-short-tags option in there anywhere. If not, listen to #phil and look for a section titled Additional .ini files parsed which may list other ini files that have been parsed.
If your search is as thorough as you suggest in your original post and you still cannot get short tags, it may be turned off in an apache configuration file or the short_open_tag directive may exist in more than one spot. A PHP.ini directive will override any prior values that might have been set.
A grep search might help. In my PHP info output, I see these values:
Loaded Configuration File - /etc/php5/apache2/php.ini
Scan this dir for additional .ini files - /etc/php5/apache2/conf.d
I can easily search all files in that location with this grep command:
grep -ir 'short_open_tag' /etc/php5/apache2
If you double/triple check all these ini files and restart apache and still can't get short_open_tag setting to work, this value may be set as an apache option. I suggest searching the apache configuration files for any reference to short_open_tag. The exact directory location may be different on your machine, but this grep command works for me
grep -ir 'short_open_tag' /etc/apache2
You should also keep in mind that your apache configuration may not be set up to even bother with .htaccess files so your attempt to override using .htaccess may be for naught unless you configure apache to actually use the .htaccess file. Assuming your apache configuration does bother parsing your htaccess file, this appears to be covered in another question here on SO.
And finally, if your server is configured to use PHP-FPM, then it uses a pool of PHP processes to handle PHP requests from the web server. If that's the case, you would need to restart php-fpm with this command:
sudo service php7.0-fpm restart
NOTE: this command may vary on different machines.
I checked which php.ini is used with phpinfo(), so I'm editing the right php config file.
In that php.ini file (and in phpinfo() details) I have display_errors at On and error_reporting at E_ALL.
BUT when I have a PHP error, most of the time I find no log (in the file specified by error_log, nor in the file specified in apache vhost, nor in /var/syslog), and only a blank page displayed.
I also tried to use the ini_set("display_errors", 1) but that didn't change anything.
One thing was weird, I had no php5 folder in /var/log (I created it, and configured error_log to use it).
Any idea would be much appreciated, that's not so great to code without knowing anything about the errors you have !
P.S. I'm using PHP 5.4 & Symfony2 (using the app_dev.php file), on Debian Wheezy.
Edit : Error logs now work thanks to #martinezjc , but still having a blank page in Apache.
You can create a custom directory, remember to assign apache permission
mkdir /var/log/php-5-4
chown www-data /var/log/php-5-4
The in the php.ini file
error_log = /var/log/php-5-4/php_errors.log
This link talk about more about logs, you can check it http://doc.exyks.org/wiki/Server_php_log_configuration
I wanted to learn more about PHP and Apache so I decided to install them manually. I don't exactly understand how the two files work together (or if they even go hand in hand in this situation). Whenever I load the localhost webpage, the location of the php files are directed from what I specify in the httpd.conf file. I've made two root folders just for the sake of testing, C:/Users/Alex/test and C:\Users\Alex\My Websites. Apache does not actually use the location that I specified in php.ini (doc_root = "C:\Users\Alex\My Websites"), but instead uses the location that I specified in httpd.conf (DocumentRoot "C:/Users/Alex/test" ). Can anyone please explain when is the root useful in php.ini?
Most likely you're running mod_php inside of Apache (this is the most common way to run PHP under Apache). That means that the PHP environment is controlled entirely by Apache (in Unix environments Apache has its own user as well). You can reconfigure it to use Fast CGI (which is the only way to run PHP under other web servers like nginx) and the setting will matter under that type of setup.
Here's the manual entry for the setting
PHP's "root directory" on the server. Only used if non-empty. If PHP
is configured with safe mode, no files outside this directory are
served. If PHP was not compiled with FORCE_REDIRECT, you should set
doc_root if you are running PHP as a CGI under any web server (other
than IIS). The alternative is to use the cgi.force_redirect
configuration below.
I've read numerous posts on this problem and none of them matches my problem exactly. I have a WordPress site (currently 3.5) on a GoDaddy virtual host. In November I opted to upgrade the O/S from CentOS 5 to CentOS 6.3, which involved a full O/S reinstall over which I had no control and about which I had no information. Following the O/S reinstall I rebuilt the site from a backup I had taken just before starting.
After the rebuild, a WordPress plugin we've been using for years, WP-DBManager, suddenly stopped backing up our mysql database. The backup fails because the backup panel claims "MYSQL path does NOT exist." Annoyingly, when you go to the DB Options page and tell it to auto-detect the mysql path, the options page produces /usr/bin/mysql, which is correct. I can log into the site with SSH and there it is. The permissions are:
-rwxr-xr-x 1 root root 338184 Jun 22 05:58 /usr/bin/mysql
This SHOULD work. SOMETHING in my site permissions changed with this rebuild and I don't know what; so far I've only documented WordPress configurations. The research I've done suggests it may be something to do with PHP safe mode. We run PHP 5.3.3, and the configuration list from phpinfo() does not show
--enable-safe-mode
which means safe mode should be OFF. The safe mode settings in php.ini when this started were:
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
safe_mode_exec_dir =
safe_mode_include_dir =
safe_mode = off
safe_mode_gid = off
I have since changed safe_mode_gid to ON, with no effect. I have a test site built from the production site, where safe_mode_include_dir = ~ so I tried that, with no effect. The test site runs PHP 5.3.14 and the safe mode settings above were identical except for safe_mode_include_dir. I checked the ENV variable and /usr/bin is included in the PATH:
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/lrservice/bin
I don't know if this is an environment variable problem, here are the safe mode entries for that:
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
These settings are not all the same on the working test site, one reads:
safe_mode_allowed_env_vars = PHP_ LANG LANG_
Since the site is fully functional except for this, I know that mysql's permissions are generally correct. Does this ring any bell for anyone?? Why am I getting all this if safe mode is officially turned off? I have a feeling there's something obvious and stupid that I'm missing.
You have access to the mysql binary from an ssh session in the /usr/bin directory, but php is unable to find it at that same location.
I am assuming that your system is using the apache2 webserver.
Is the ChrootDir directive present in the apache configuration file (usually located at /etc/httpd/conf/httpd.conf)?
If that's the case, you can check in the directory pointed by this directive if there is a link to the mysql binary. If not, simply add it by executing the following command (assuming you have the priviledges to do so) in your ssh session:
$ ln /usr/bin/mysql /chroot/path/usr/bin/mysql
with /chroot/path replaced by the ChrootDir directive path.
One of the comments mentions the open_basedir PHP setting, which can be configured either in php.ini, httpd.conf, or .htaccess files.
This setting limits access to certain directory of the filesystem available to PHP. A possible fix is to remove this restriction for the scripts executed by the plugin you are using, if that setting is not protected:
locate the scripts installed by the plugin in your wordpress directory,
create a .htaccess file lifting the restriction in the directory containing the scripts with the following commands:
$ echo 'php_value open_basedir none' >> .htaccess
The above will add the text between simple quote at the end of the .htaccess file, creating it if necessary.
This solution is probably the safest, as it reduces the security relaxing to only these scripts. You should be wary that you are going to let these scripts potentially have access to much more than they really need to operate.
If the above does not work, it means that the setting is protected, and must be changed in either httpd.conf or php.ini which should be both located within the /etc directory. See this SO question for details.
Is it possible to make changes to .ini php file to maximize the excecution time of php scripts?
I am owner of a reseller package at hostgator and a vps at inmotionhosting. There isn't any property or option to change it via cpanel or whm.
So I ask if there is any other way, like to manually create this file, place it to the server via ftp and restart php my admin.
If you have access to the php folder where php.ini is held then you can just edit that.
The property you are looking for is called max_execution_time
Yes, you can edit the php.ini usually located in /usr/local/lib/php.ini then restart httpd which will update it. You can't normally access php.ini via FTP so you would need to use SSH to do this or find php.ini via a file manager on your container software.
Alternatively, you can set execution limits on a per script basis with
set_time_limit()
Additionally you can use
ini_set()
to change the value of any php configuration variable at runtime. Try ini_set('max_execution_time'). Your host may have disabled certain configurations so this will not work on all servers.