iis+php环境
有客户反映在VPS中出现该错误:PHP has encountered an Access Violation at *
根据错误提示,可以用以下办法解决:
1、重启IIS,重启VPS主机即可。
2、关闭eaccelerator扩展
找到php.ini
如果是我帮您配置的,一般在c:/windows/php.ini
去掉
zend_extension_ts="C:phpextensionseaccelerator_win_xxx.dll"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="c:temp"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
3、session_save_path 需要设定一个实际的物理路径,并且该目录需要everyone的所有权限,类似U主机的0777
4、您的内存严重不足
5、ZendOptimizer和php的搭配不是很好,换个版本试试看
6、这种多属于用win2003的用户,他们在应用池中设定了限制,比如多长时间回收,最大使用内存多少等等
技术部门推荐,重启IIS即可,因为这个错误出现的几率非常低。
php+apache环境
1、更新到5.2后php版本
2、是否zend所需的dll文件所在目录给的权限不够,必须有读取和运行的权限
3、如果使用的是windows系统,是否设置过应用池,比如池中限制了什么
4、高版本的PHP和Mysql存在兼容性的问题。c:/windows/system32下的libmysql.dll 使用php下的,不要使用mysql下的,因为两个程序下都有
5、php.ini有两个地方没有设置
1)
将;upload_tmp_dir该行的注释符,即前面的分号“;”去掉,使该行在php.ini文档中起作用。
upload_tmp_dir是用来定义上传文件存放的临时路径,在这里你还可以给其定义一个绝对路径
比如:upload_tmp_dir = d:\tmp
(d:\tmp目录必须有读写权限)
2)
php.ini中关于session.save_path一项没有设置好,解决的方法是将
session.save_path和session.cookie_path 定义一个绝对路径
比如:
session_save_path = d:\temp
session.cookie_path = d:\temp
(d:\tmp目录必须有读写权限)
或者因为安装了一些组件导致。都可以参考下。
最近我的windows2003服务器频繁出现“PHP has encountered an Access Violation at ××××××”这样的错误,尝试搜索了下,遇到这样问题的人还真不少。我的原因可以锁定在eaccelerator上面,因为之前php运行效率不大满意,所以装了eaccelerator加速,效果还是不错的,但随着数据库不断加大,查询和更新数据库操作太频繁,出现了“PHP has encountered an Access Violation at ××××××”这个错误。网上的解决办法无非就是去掉eaccelerator加速,这肯定不行,因为我要用,那就按他们说的配置一下吧,什么临时文件啊、session路径啊,都改了,还是不行,于是就想是不是mysql版本的问题呢?看了下,发现dll的大小和修改日期还真不一致,于是把mysql下的dll覆盖了从php里拷贝到系统目录的dll,重启iis,貌似好了,但是重启服务器后又出现了,看来问题不在这,难道是iis应用程序池的问题?
尝试去除这个站点的所有限制,但是重启服务器后发现又不行,还是这个错误。观察了下,只要重启iis就能临时解决这个问题,但是这不治本啊。仔细想了下,既然我的环境没有问题,是在装了eaccelerator后出现问题,那就从eaccelerator下手。仔细检查每个配置,发现我配置的一点问题都没有,无论eaccelerator的版本、php的版本,还是mysql的版本,都没问题,权限也都够,php.ini配置也正确,但重启iis就好使一阵子,于是把问题定位到应用程序池。因为我的iis之前配置一点问题都没有。最近看eaccelerator资料是共享内存和硬盘,难道是iis应用程序池和其他站点共享导致这个问题?于是重新建立应用程序池,把这个应用程序池只独立分配给出问题的站点,适当减少对资源的限制,重启iis,好使了,重启服务器,也好使了,做了个简单的压力测试,也好使了。
环境:linux ,apache2 ,php5
问题:打开phpmyadmin出现如下错误:
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.
解决办法如下:
vim /etc/php5/apache2/php.ini
查找session.save_path ,将session.save_path=/var/lib/php5这一句的注释符号去掉。
如还不能正常工作,将session.auto_start的值改为1(启动),默认是0(禁用)
这个错误一般是由于session文件的存储路径不可写造成的,在linux下一般是路径的权限问题。在windows下面session.save_path一定要设置到一个可以读写的路径,如 D:/tmp 等。
今天在一朋友服务器测试一个网站时发现我在测试phpinfo时碰到PHP Warning: phpinfo() has been disabled for security reasons 提示了,按话的意思我总结了解决办法,下面我们一起来看看吧。
在运行phpinfo时碰到提示如下
PHP Warning: phpinfo() has been disabled for security reasons in XX.php on line XX
这段话的意思是告诉我们由于安全考虑 phpinfo() 函数被禁用, 如果你有服务器管理权限请修改 php.ini 配置文件参数并重启apache 重新启用.
打开php安装路径打开php.ini文件
具体实例
在php.ini中存在 disable_functions配置,默认配置中,cli执行函数都是被 禁止的,如果需要的话,需要在php.ini中将 disable_functions = phpinfo,exec , popen, system …. ,将你需要执行的函数从列表中删掉在重启apache即可 。
完全是配置的问题。
linux中解决办法
编辑PHP配置文件:
vi /usr/local/php/etc/php.ini
寻找disable_functions字符串,将后面的scandir删除(提示:vi下可输入/,进入搜索模式,轻松找到disable_functions)
重启PHP生效
/etc/init.d/php-fpm restart
使用uft8编码或做页面的朋友会碰见过把页面保存时会发现页面是空白的但是页面确实有内容,后会会听说是bom头的问题,那么什么是bom头了,要如何解决因为bom头导致页面空白问题呢,下面我们一起来看看具体解决办法。
Unicode规范中有一个BOM的概念。BOM——Byte Order Mark,就是字节序标记。在这里找到一段关于BOM的说明:
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输 字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。
UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。
另外unicode网站的FAQ-BOM详细介绍了BOM。官方的自然权威,不过是英文的,看起来比较费劲。
UTF- 8编码的文件中,BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话,用UE打开这个文件,切换到十六进制编辑状态就可以看到开 头的FFFE了。这是个标识UTF-8编码文件的好办法,软件通过BOM来识别这个文件是否是UTF-8编码,很多软件还要求读入的文件必须带BOM。可 是,还是有很多软件不能识别BOM。我在研究Firefox的时候就知道,在Firefox早期的版本里,扩展是不能有BOM的,不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现,PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题,也就是说他不会忽略 UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行,所以这三个字符将会直接输 出。如果遇到header(),session(),cookie()等问题,将会导致乱码或显示白屏等问题.
去掉BOM头?
去掉BOM头的办法,最简单就是使用editplus或ultraedit等软件来操作。具体展示如下:
1、使用editplus去除BOM头
编辑器调整为UTF8编码格式后,保存的文件前面会多出一串隐藏的字符(也即是BOM),用于编辑器识别这个文件是否是以UTF8编码。
运行Editplus,点击工具,选择首选项,选中文件,UTF-8标识选择总是删除签名,然后对PHP文件编辑和保存后的PHP文件就是不带BOM的了。
2、使用ultraedit去除BOM头
打开文件后,“另存为”选项的编码格式里选择(UTF-8 无BOM头),确定就OK了
3、利用php批量去掉所有文件BOM头
代码如下 | 复制代码 |
<?php $auto = 1; $dirname = $basedir."/".$file; |
先们来看例子
例子
代码如下 | 复制代码 |
function geturl( $url,$userinfo,$header) |
执行一会发现
Fatal error: Maximum execution time of 30 seconds exceeded in D:phpAppServwww360dtest.php on line 3
后面我在页面顶部加上
代码如下 | 复制代码 |
set_time_limit(0);//设置超时时间 |
这样就没有问题了,下面我再简单介绍一下set_time_limit详解
set_time_limit — 限制最大的执行时间set_time_limit(PH3 , PHP4)set_time_limit — 限制最大的执行时间语法 : void set_time_limit (int seconds)说明 : 设定一个程式所允许执行的秒数,如果到达限制的时间,程式将会传回错误。
它预设的限制时间是30秒,max_execution_time的值定义在结构档案中(在PHP3中叫做php3.ini,在PHP4、PHP5则叫做php.ini),如果将秒数设为0,表示无时间上的限制。
当呼叫此函式时,set_time_limit()会从零重新开始计算最长执行的时间,也就是说,如果最长执行时间为预设的30秒,而在呼叫此函式set_time_limit(20)之前已花了25秒来执行程式,则程式最长执行的时间将会是45秒。
有些朋友说可以修改apache%C5%E4%D6%C3/" target="_blank">apache配置,但我没测试大家自动设置吧。
1、 修改是APACHE设置,在PHP.INI中找到一个参数:
max_execution_time
将后面的值调大,然后重新启动APACHE服务(centos: service httpd restart),就OK了。
如
max_execution_time = 600