Snapshot of the output of phpinfo() function:
As I am trying to install Roundcube which requires to set date.timezone, I would like to set date.timezone by filling the date.timezone field in php.ini.
Server Configuration
Debian 9 (Stretch)
PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
Apache/2.4.25 (Debian)
What I tried
According to http://php.net/manual/en/timezones.php, I modified the date.timezone field from both /etc/php/7.0/apache2/php.ini and /etc/php/7.0/cli/php.ini with different syntaxes:
date.timezone = Europe/Paris
date.timezone = 'Europe/Paris'
date.timezone = "Europe/Paris"
And I always restarted Apache after any change.
Nothing change in phpinfo, the date.timezone field is always set to "no value" and the first step of the installation of Roundcube, date.timezone is NOT OK.
But when I try:
php -i
I get:
date/time support => enabled
"Olson" Timezone Database Version => 0.system
Timezone Database => internal
Default timezone => Europe/Paris
Directive => Local Value => Master Value
date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => Europe/Paris => Europe/Paris
I read many pretty old posts about this type of issue but the different solutions did not work for me. Any idea?
EDIT
According to phpinfo():
Configuration File (php.ini) Path
/etc/php/7.0/apache2
Loaded Configuration File
/etc/php/7.0/apache2/php.ini
Scan this dir for additional .ini files
/etc/php/7.0/apache2/conf.d
Additional .ini files parsed
/etc/php/7.0/apache2/conf.d/10-mysqlnd.ini, /etc/php/7.0/apache2/conf.d/10-opcache.ini, /etc/php/7.0/apache2/conf.d/10-pdo.ini, /etc/php/7.0/apache2/conf.d/15-xml.ini, /etc/php/7.0/apache2/conf.d/20-calendar.ini, /etc/php/7.0/apache2/conf.d/20-ctype.ini, /etc/php/7.0/apache2/conf.d/20-curl.ini, /etc/php/7.0/apache2/conf.d/20-dom.ini, /etc/php/7.0/apache2/conf.d/20-exif.ini, /etc/php/7.0/apache2/conf.d/20-fileinfo.ini, /etc/php/7.0/apache2/conf.d/20-ftp.ini, /etc/php/7.0/apache2/conf.d/20-gd.ini, /etc/php/7.0/apache2/conf.d/20-gettext.ini, /etc/php/7.0/apache2/conf.d/20-iconv.ini, /etc/php/7.0/apache2/conf.d/20-imagick.ini, /etc/php/7.0/apache2/conf.d/20-imap.ini, /etc/php/7.0/apache2/conf.d/20-intl.ini, /etc/php/7.0/apache2/conf.d/20-json.ini, /etc/php/7.0/apache2/conf.d/20-mbstring.ini, /etc/php/7.0/apache2/conf.d/20-mcrypt.ini, /etc/php/7.0/apache2/conf.d/20-memcache.ini, /etc/php/7.0/apache2/conf.d/20-mysqli.ini, /etc/php/7.0/apache2/conf.d/20-pdo_mysql.ini, /etc/php/7.0/apache2/conf.d/20-pdo_sqlite.ini, /etc/php/7.0/apache2/conf.d/20-phar.ini, /etc/php/7.0/apache2/conf.d/20-posix.ini, /etc/php/7.0/apache2/conf.d/20-pspell.ini, /etc/php/7.0/apache2/conf.d/20-readline.ini, /etc/php/7.0/apache2/conf.d/20-recode.ini, /etc/php/7.0/apache2/conf.d/20-shmop.ini, /etc/php/7.0/apache2/conf.d/20-simplexml.ini, /etc/php/7.0/apache2/conf.d/20-snmp.ini, /etc/php/7.0/apache2/conf.d/20-sockets.ini, /etc/php/7.0/apache2/conf.d/20-sqlite3.ini, /etc/php/7.0/apache2/conf.d/20-sysvmsg.ini, /etc/php/7.0/apache2/conf.d/20-sysvsem.ini, /etc/php/7.0/apache2/conf.d/20-sysvshm.ini, /etc/php/7.0/apache2/conf.d/20-tidy.ini, /etc/php/7.0/apache2/conf.d/20-tokenizer.ini, /etc/php/7.0/apache2/conf.d/20-wddx.ini, /etc/php/7.0/apache2/conf.d/20-xmlreader.ini, /etc/php/7.0/apache2/conf.d/20-xmlrpc.ini, /etc/php/7.0/apache2/conf.d/20-xmlwriter.ini, /etc/php/7.0/apache2/conf.d/20-xsl.ini
I faced the similar problem problem.
'date.timezone' in php.ini is showin as 'not set' / 'no value' when running php under apache. Checked through phpinfo(). Issue not solved even when apache is restarted. It is solved by restarting php-fpm service ( Fast cgi process manager).
systemctl restart php-fpm
[I am not a native speaker of English. I tried my best to edit the answer after going through the message in my stackoverflow INBOX].
I have found the problem. It was a syntax error in my php.ini file in the error_reporting area.
Let me contribute something: I was installing SilverStripe on a VPS and had the exact same problem. I have been searching the answer the whole late afternoon without positive outcome. After all attempts, I removed the ";" in front of
[Date]
; Defines the default timezone used by the date functions
;date.timezone = Europe/London
Here is where I got the answer:
https://www.silverstripe.org/community/forums/installing-silverstripe/show/15398?start=8
Hope everyone avoids this trouble
I noticed it was different in two places in my php.ini file for xampp, here:
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = "America/Phoenix"```
and here:
; List of headers files to preload, wildcard patterns allowed.
;ffi.preload=
[Syslog]
define_syslog_variables=Off
[Session]
define_syslog_variables=Off
[Date]
date.timezone=Europe/Berlin```
Note they are different--I have no idea how "Europe/Berlin" got in my php.ini. I noticed this showing up in my php error logs and searched through the whole xampp folder.
php_info() will always indicate the path of the .ini that's being used, ensure this is correct, and aligns with the ini that your are editing.
Related
I am using Apache 2.4.7 with mod_wsgi 3.4 on Ubuntu 14.04.2 (x86_64) and python 3.4.0. My python app relies on apache to perform user authentication against our company’s LDAP server (MS Active Directory 2008). It also passes some additional LDAP data to the python app using the OS environment. In the apache config, I query the LDAP like so:
…
AuthLDAPURL "ldap://server:389/DC=company,DC=lokal?sAMAccountName,sn,givenName,mail,memberOf?sub?(objectClass=*)"
AuthLDAPBindDN …
AuthLDAPBindPassword …
AuthLDAPRemoteUserAttribute sAMAccountName
AuthLDAPAuthorizePrefix AUTHENTICATE_
…
This passes some user data to my WSGI script where I handle the info as follows:
# Make sure the packages from the virtualenv are found
import site
site.addsitedir('/home/user/.virtualenvs/ispot-cons/lib/python3.4/site-packages')
# Patch path for app (so that libispot can be found)
import sys
sys.path.insert(0, '/var/www/my-app/')
import os
from libispot.web import app as _application
def application(environ, start_response):
os.environ['REMOTE_USER'] = environ.get('REMOTE_USER', "")
os.environ['REMOTE_USER_FIRST_NAME'] = environ.get('AUTHENTICATE_GIVENNAME', "")
os.environ['REMOTE_USER_LAST_NAME'] = environ.get('AUTHENTICATE_SN', "")
os.environ['REMOTE_USER_EMAIL'] = environ.get('AUTHENTICATE_MAIL', "")
os.environ['REMOTE_USER_GROUPS'] = environ.get('AUTHENTICATE_MEMBEROF', "")
return _application(environ, start_response)
I can then access this info in my python app using os.environ.get(…). (BTW: If you have a more elegant solution, please let me know!)
The problem is that some of the user names contain special characters (German umlauts, e.g., äöüÄÖÜ) that are not encoded correctly. So, for example, the name Tölle arrives in my python app as Tölle.
Obviously, this is an encoding problem, because
$ echo "Tölle" | iconv --from utf-8 --to latin1
gives me the correct Tölle.
Another observation that might help: in my apache logs I found the character ü represented as \xc3\x83\xc2\xbc.
I told my Apache in /etc/apache2/envvars to use LANG=de_DE.UTF-8 and python 3 is utf-8 aware as well. I can’t seem to specify anything about my LDAP server. So my question is: where is the encoding getting mixed up and how do I mend it?
It is bad practice to copy the values to os.environ on each request as this will fail miserable if the WSGI server is running with a multithreaded configuration, with concurrent requests interfering with each other. Look at thread locals instead.
As to the issue of encoded data from LDAP, if I under stand the problem, you would need to do:
"Tölle".encode('latin-1').decode('utf-8')
I have the following CGI script:
#!c:\cygwin\bin\perl.exe
use CGI qw(:standard);
my $query = $CGI->new;
print header (
-type => "text/html",
-status => "404 File not found"
);
print "<b>File not found</b>";
This gives me an error:
Server error!
The server encountered an internal error and was unable to complete your request.
Error message:
End of script output before headers: test.cgi
If you think this is a server error, please contact the webmaster.
Error 500
127.0.0.1
Apache/2.4.10 (Win32) OpenSSL/1.0.1h PHP/5.4.31
I've looked at this (and other similar) question(s), but there the headers were not being printed, as opposed to mine.
I'm using the XAMPP Windows package with Cygwin Perl.
Can anyone help? Thanks.
I don't know why you are using $CGI instead of CGI
I think It should be
my $query = CGI->new;
tested on Linux working perfect.
So, as others have pointed out, your problem was using a variable ($CGI) where you actually needed a class name (CGI). But, in my mind, this raises two more questions.
1/ Why are you trying to create a CGI object in the first place? You are using the function-based interface to CGI (print header(...) for example) so there's no need for a CGI object.
2/ Why are you writing a CGI program in 2014? Perl web programming has moved on a long way this millennium and you seem to be stuck in the 1990s :-/
I've downloaded and installed Apache 2.4.4 (which now comes with mod_lua module). Enabled it like so:
--httpd.conf--
LoadModule lua_module modules/mod_lua.so
AddHandler lua-script .lua
and ran a simple script and it works.
--htdocs/hello.lua--
function handle(r)
r.content_type = "text/html"
r:puts("Hello Lua World!\n")
end
I'd now like to connect to a local pg database but can't get it work.
function handle(r)
r.content_type = "text/html"
r:puts("Hello Lua World!\n")
local db, err = r:dbacquire("postgres", "postgres://user:secret#localhost/db0")
if not err then
r:puts("connected!")
else
r:puts("couldn't connect!")
end
end
No error messages whatsoever. Am I missing further configuration?
Thanks for any input!
Apache httpd is based on APR which provides the database connectivity;
so make sure that your APR installation supports the database layer you want to use.
Turns out I got the driver name and connection string wrong. Replacing the dbacquire line in the question with this should make it work.
db = r:dbacquire("pgsql", "hostname=localhost dbname=foo user=bar password=baz")
Better yet, by embedding these in the httpd.conf like so
DBDriver pgsql
DBDParams "hostname=localhost dbname=foo user=bar password=baz"
You can get away by simply doing this in your lua scripts
db = r:dbacquire()
--start using your db here
I have set up log4r as per outlined here: "How to configure Log4r with Rails 3.0.x?"
However now I'm faced with unicorn not sending its output to the log4r logs. How do you do this?
does this comment help?
in your config, Rails isn't overriding the "file" config value of the
outputter - the argument is "filename" :) It defaults to the name of
the file/command that started the process. Note that any custom file
name you specify must have a file extension, or it will fail to stick
the date in the file name! – Nevir Aug 24 '11 at 22:05
I have a PHP script that keeps stopping at the same place every time and my browser reports:
The connection to the server was reset
while the page was loading.
I have tested this on Firefox and IE, same thing happens. So, I am guessing this is an Apache/PHP config problem. Here are few things I have set.
PHP.ini
max_execution_time = 300000
max_input_time = 300000
memory_limit = 256M
Apache (httpd.conf)
Timeout 300000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 0
Are the above correct? What can be causing this and what can I set?
I am running PHP (5.2.12.12) as a
module on Apache (2.2) on a Windows
Server 2003.
It is very likely this is an Apache or PHP issue as all browsers do the same thing. I think the script runs for exactly 10 mins (600 seconds).
I had a similar issue - turns out apache2 was segfaulting. Cause of the segfault was php5-xdebug for 5.3.2-1ubuntu4.14 on Ubuntu 10.04 LTS. Removing xdebug fixed the problem.
I also had this problem today, it turned out to be a stray break; statement in the PHP code (outside of any switch or any loop), in a function with a try...catch...finally block.
Looks like PHP crashes in this situation:
<?php
function a ()
{
break;
try
{
}
catch (Exception $e)
{
}
finally
{
}
}
This was with PHP version 5.5.5.
Differences between 2 PHP configs were indeed the root cause of the issue on my end. My app is based on the NuSOAP library.
On config 1 with PHP 5.2, it was running fine as PHP's SOAP extension was off.
On config 2 with PHP 5.3, it was giving "Connection Reset" errors as PHP's SOAP extension was on.
Switching the extension off allowed to get my app running on PHP 5.3 without having to rewrite everything.
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"
It's an old post, I know, but since I couldn't find the solution to my problem anywhere and I've fixed it, I'll share my experience.
The main cause of my problem was a file_exists() function call.
The file actually existed, but for some reason an extra forward slash on the file location ("//") that normally works on a regular browser, seems not to work in PHP. Maybe your problem is related to something similar. Hope this helps someone!
I'd try setting all of the error reporting options
-b on error batch abort
-V severitylevel
-m error_level
and sending all the output to the client
<?php
echo "<div>starting sql batch</div>\n<pre>"; flush();
passthru('sqlcmd -b -m -1 -V 11 -l 3 -E -S TYHSY-01 -d newtest201 -i "E:\PHP_N\M_Create_Log_SP.sql"');
echo '</pre>done.'; flush();
My PHP was segfaulting without any additional information as to the cause of it as well. It turned out to be two classes calling each other's magic __call() method because both of them didn't have the method being called. PHP just loops until it's out of memory. But it didn't report the usual "Allowed memory size of * bytes exhausted" message, probably because the methods are "magic".
I thought I would add my own experience as well.
I was getting the same error message, which in my case was caused by a PHP error in an exception.
The culprit was a custom exception class that did some logging internally, and a fatal error occurred in that logging mechanism. This caused the exception to not be triggered as expected, and no meaningful message to be displayed either.