大家在使用Nginx版更改过配置文件时,upupw面板经常会提示MySQL 1067错误或Nginx 1067错误服务无法启动等。
首先大家遇到这种情况不要急,可以肯定的是这种错误的出现都是跟nginx.conf/vhosts.conf/up-rewrite.conf/my.ini/php.ini等配置文件有关的。 Nginx对错误的配置文件非常之敏感哪怕是一丁点错误她就无法启动了! 下面来讲解下1067错误产生的原因和具体解决办法: 1、超级无敌大错特错不能容忍的操作习惯-用记事本修改配置文件引起的1067错误 由于这种原因修改.conf为后缀的配置文件产生的1067错误是毁灭性的,只要你用记事本编辑保存了配置文件,不管你怎么尝试都无法启动,用其它软件再次编辑保存也无效,直到你拿原始文件覆盖为止。 推荐用源代码编辑利器Notepad6.3.3简体中文绿色版编辑配置文件 2、用旧版本的配置参数作为新版本的参数修改配置文件引起的1067错误 主要体现在修改MySQL数据库文件my.ini后出现的1067错误,可以查看MySQL\data目录下的xxxxx.err文件一般系统会提示错误内容并给出正确建议,请大家多参照与版本对应的配置说明去修改文件。 如果是修改Nginx的nginx.conf/vhosts.conf/up-rewrite.conf引起的1067错误请查看Nginx\logs目录下的error.log文件根据提示修正错误即可正常启动。 3、Nginx伪静态规则不正确引起的1067错误 如果伪静态规则是自己写的或者是由apache版转换过来的出现1067的错误率会特别高,因为你还在修改伪静态根本无法保证其准确性,这种情况可以先去除伪静态看服务能否启动,直到把伪静态规则改对为止。 4、服务路径不对引起的1067错误 这种情况一般是在没按S5结束全部服务,就开始两种版本如N2/N3交替使用造成的,也可能是在没按S5结束全部服务就对当前版本进行升级造成的,还有就是没按S5就把upupw文件夹挪到其它目录启动造成的。 因为服务是用于识别目录程序路径用以启动当前程序的,如果不先结束服务,那么很容易造成下个版本的程序还使用当前程序的服务识别到的是当前程序的路径。 处理这种因素造成的1067错误很简单只要回到原目录按s5结束全部服务直到服务面板内没有upupw_开头的服务名即可启动了,或者用UPUPW系统服务清理工具清理服务后再启动即可! 5、端口冲突引起的1067错误 这种情况一般打开面板输入4确定后看看端口是否被占用就可以判断了,关闭占用端口程序或更改自身端口后重新启动即可。 备注:Apache版本中遇到的1067错误解决方法同上 |
|
最新喜欢:solier |
板凳#
发布于:2013-11-05 15:19
NGINX启动出现1067错误还有一种原因是vhosts.conf出现问题而启动不了,解决方法可以用之前备份的vhosts.conf覆盖一下或者下载一个新的UPUPW把里面的vhosts.conf复制出来覆盖出问题的文件,然后重新绑定域名
|
|
地板#
发布于:2015-06-09 21:20
正常运行的,然后第二天突然就数据库1067了,重启了没用,KK了再启动也没用
|
|
4楼#
发布于:2015-06-09 22:01
kk后面板输入4看看3306端口是否被占用,如果被占用就是端口冲突了需要先停用占用程序。
另外数据表出错也会提示3306错误,此时可以看数据库data目录的.err报告文件的 [error]项。 |
|