phpmyadmin报错：Cannot start session without errors问题

在使用phpmyadmin时发现Cannot start session without errors问题解决办法，希望此文章能给你带来帮助哦。

解决方法一，nginx 环境

在一个新环境中，装了一个phpmyadmin
发现打开的时候提示：Cannot start session without errors….
然后登陆的时候，也发现样式等等的错误，
解决办法：
是php环境中session存放目录的权限访问问题
先打开php.ini
查找：session.save_path
检查路径下的目录的所有者是否正常：
root apache 4096 Mar 15 23:07 session
如果是这样的，明显不正常
应该改成：
apache apache 4096 Mar 15 23:07 session
或
nginx nginx 4096 Mar 15 23:07 session
等等。
另外请注意！，如果是nginx + php-fpm，除了检查/etc/php.ini 的设置外也要检查：
/etc/php-fpm.d/www.conf 的

php_value[session.save_path] = /var/lib/php/session

这个session的存储路径必须和php.ini 的一致！！！

解决办法二

环境：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（禁用）

解决办法三

Windows Server 2003 + IIS6 (ISAPI mode php +zend)

在php的目录建立个文件夹Temp,设置Temp属性为IIS_Users组除完全控制的所有权限。(IIS_Users为IIS匿名用户组)

在php.ini找到session.save_path 这一行,设成session.save_path = “D:/host/php/Temp”(把分号去掉)。

解决办法：

将php.ini中的session.auto_start的值改为1（启动），默认是0（禁用），
在php.ini找到session.save_path 这一行,设成session.save_path = “D:/host/php/Temp” (把分号去掉)

在phpmyadmin中找到，config.sample.inc.php,改成config.inc.php,
找到 $cfg['blowfish_secret'] 将后面的赋值，加入数字和字母组合。

在运行dedecms是有些朋友会发现有些页面会提示Fatal error: Allowed memory size of 134217728 bytes exhauste错误了，下面我们一起来看看解决此问题办法。

报错提示：Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 38218371 bytes) in .....

解决方法：

1.取消PHP的内存限制。
在php程序中添加 ini_set("memory_limit","-1");
2.根据自己的需要及参考本机的内存大小修改php内存限制，如改为1024M。
在php程序中添加 ini_set("memory_limit","1024M"); 或者将php.ini中相应位置改为memory_limit = 1024M;

内存限制的意义

php中的相关文档解释 memory_limit 如下:

memory_limit： integer

该指令设定了一个脚本 所能够申请到的最大内存字节数。这有助于防止写得不好的脚本消耗光服务器上的可用内存。要使用此指令必须在编译的时候激活。因此 configure 一行中应该包括：--enable-memory-limit。如果不需要任何内存上的限制，必须将其设为 -1。 从 php 4.3.2 起，当激活了 memory_limit，PHP 函数 memory_get_usage() 便可以使用了。也就是说，php在一个 page 中的处理内存限制，默认的(/etc/php.ini)定义为 128M (我的系统默认安装后)，后来开发组的应用写的越来越复杂，但是在结构上可能还有些欠缺，频繁的对象请求，居然造成了内存不足。

应用层面测试与解决方法

最好的方式应该在应用层面解决，而不是不断的增加内存设置。以下为代码测试：

代码如下	复制代码
<? printf(" total run: %.2f s<br>". "memory usage: %.2f M<br> ", microtime(true)-$HeaderTime, memory_get_usage() / 1024 / 1024 ); ?>

运行结果显示如下：

total runtime: 1.47 s

memory usage: 77.09 M

一个页面居然会有77M的请求。究其原因，是程序员在编码时，仅仅对变量赋值，却从来没有 unset ($var) 过。试想，如果一个页面请求要处理20个sql查询，每个sql查询返回10个sql结果，而程序员从来都不关心是返回一个row的所有column还是仅仅返回需要的column(实际上当我们采用更common的中间层时，往往会返回全部的column而不是特定的某几个字段，就像在 ORM 中如NHibernate, JBOSS中的那样)如果一条row有10K, 那么这个页面到处理结束时就要增加到 10K*10*20=2M的数组分配，这还不算有时候我们需要最数组进行复制。

所以在php中，合理的方法是变量使用后就 unset($var)，最大限度节省内存资源。

经验之谈

本人有一台服务器使用的是apaceh2.3与php5.2.6上面的方法无效，经官方确认是php版本bug了，我们可以换个高版本手php版本即可解决。

php5.3.9中增加了一个 max_input_vars 变量，如果你post提交的数据超出来了 max_input_vars 值就会有部分数据丢失了。

最近在项目中，出现一个奇怪的现象，有一个大form里面有上千个input，提交的时候，老是发现post过来的数据不完整，一开始还怀疑是html 表单名称有冲突，排除掉了。

然后，网上找了一堆，php.ini 的post_max_size和upload_max_filesize都设置了很大的值，没用，nginx的client_max_body_size 500m;加到了那么大的值，也没用。

最后终于google到办法：

原来PHP从5.3.9开始增加一个变量 max_input_vars 用来限制提交的表单数量,实在无语。

该值默认情况下是1000 ， 不能满足有1000个以上输入项的需求，所以得在php.ini 里面加上更大的值如：

max_input_vars = 5000 ，修改后重启php，终于一切正常！

在写一个简单的程序时碰到Parse error: syntax error, unexpected T_ENDWHILE in www.111cn.net .php文件了，下面我给大家分析一下原因与解决方法。

问题现象：

1、同样的代码，在某些机器上运行正常，但在特定机器上运行报错。

2、同一站点部分页面显示正常（例如<?php phpinfo();?>），但打开部分页面时，phpxx_errors.log或者页面显示错误提示“Parse error: syntax error, unexpected T_ENDWHILE in xx.php on line xx”。

错误原因：

该错误有可能是因为编写PHP脚本时丢失一个花括号(“}”)，但更常见的原因是php.ini文件中short_open_tag值为Off导致的。

决定是否允许使用 PHP 代码开始标志的缩写形式（<? ?>）。如果要和 XML 结合使用 PHP，可以禁用此选项以便于嵌入使用 <?xml ?>。否则还可以通过 PHP 来输出，例如：<?php echo '<?xml version="1.0"'; ?>。如果禁用了，必须使用 PHP 代码开始标志的完整形式（<?php ?>）。

Note: 本指令也会影响到缩写形式 <?= ，它和 <? echo 等价。使用此缩写需要设置 short_open_tag 的值为 On。不推荐使用短标签，使用<?php ?>才是规范的方法，但因为这种短标签使用的时间比较长（历史原因），为兼容老代码，这种特性才被保存了下来。

解决方案：

将php.ini文件中short_open_tag值设置为On。

相关知识：PHP短标签short_open_tag

名字	默认	可修改范围	更新日志
short_open_tag	"1"	PHP_INI_ALL	在 PHP 4.0.0 时是 PHP_INI_ALL。 在 PHP < 5.3.0 时是 PHP_INI_PERDIR。
asp_tags	"0"	PHP_INI_PERDIR	在 PHP 4.0.0 时是 PHP_INI_ALL。
precision	"14"	PHP_INI_ALL
serialize_precision	"17"	PHP_INI_ALL	从 PHP 4.3.2 起可用。在 PHP 5.3.5以前，默认值为 100
y2k_compliance	"1"	PHP_INI_ALL	在 PHP 5.4.0 中移除该选项。
allow_call_time_pass_reference	"1"	PHP_INI_PERDIR	在 PHP 4.0.0 时是 PHP_INI_ALL。 在 PHP 5.4.0 中移除该选项。
disable_functions	""	php.ini only	从 PHP 4.0.1 起可用。
disable_classes	""	php.ini only	从 PHP 4.3.2 起可用。
exit_on_timeout	""	PHP_INI_ALL	从 PHP 5.3.0 起可用。
expose_php	"1"	php.ini only
zend.multibyte	"0"	PHP_INI_ALL	从 PHP 5.4.0 起可用
zend.script_encoding	NULL	PHP_INI_ALL	从 PHP 5.4.0 起可用
zend.signal_check	"0"	PHP_INI_SYSTEM	从 PHP 5.4.0 起可用
zend.ze1_compatibility_mode	"0"	PHP_INI_ALL	从 PHP 5.0.0起可用。 在 PHP 5.3.0 中移除该选项
detect_unicode	"1"	PHP_INI_ALL	从 PHP 5.1.0起可用。 本过时特性将肯定会在未来被移除。

 

我在在php管方下载php版时会看到有一个，None-Thread Safe与Thread Safe版了，那么这两个版本到底有什么区别，但仔细一下看面有介绍是建义我们使用线程安全，而非线程序安全用于测试。

先从字面意思上理解，None-Thread Safe就是非线程安全，在执行时不进行线程（thread）安全检查；Thread Safe就是线程安全，执行时会进行线程（thread）安全检查，以防止有新要求就启动新线程的 CGI 执行方式耗尽系统资源。

再来看PHP的两种执行方式：ISAPI和FastCGI。FastCGI执行方式是以单一线程来执行操作，所以不需要进行线程的安全检查，除去线程安全检查的防护反而可以提高执行效率，所以，如果是以 FastCGI（无论搭配 IIS 6 或 IIS 7）执行 PHP ，都建议下载、执行 non-thread safe 的 PHP （PHP 的二?位?n有?煞N包?方式：msi 、zip ，?下? zip 套件）。而线程安全检查正是为ISAPI方式的PHP准备的，因为有许多php模块都不是线程安全的，所以需要使用Thread Safe的PHP。

说到这里，大家应该知道应该如何选择哪个版本的PHP了。None-Thread Safe or Thread Safe，您会选择哪个？

最后总结

1.Non Thread Safe（非线程安全）版本php适用在使用CGI以及fastCGI的web服务器上,如nginx,lighttpd以及IIS的CGI模式下

2.Thread Safe（线程安全）版本php适用在使用ISAPI或者module的web服务器上,如IIS的ISAPI模式或者apache module模式