[ERROR] Can’t open shared library ‘udf.dll’ (errno: 0 )

有3个多月没写博客了,现在似乎越来越懒了:( 今天竟然忘记了登录密码,幸好,输入几次终于想起来了……

如标题,[ERROR] Can’t open shared library ‘udf.dll’ (errno: 0 )

这是MySQL在启动时报的一个错误,在一个朋友的服务器上看到的,这个错误几乎已经持续了很久很久了,虽然报错,但似乎不影响使用,只不过,对于一个很洁癖的人来说,每次看到都很闹心。

之前曾经尝试过查找原因,包括建立plugin目录,以及遍历整个系统来查找udf.dll,都没什么结果。

也在谷歌和度娘上找过,说是什么提权文件,实话说,用了这么多年还真从来没听过这个功能……也按搜索到的文章操作过,但全部都是失败。

最后,考虑到可以尝试升级一下MySQL的版本(之前是5.0很早期的一个版本),由于系统还有很多不太熟悉的程序,所以为了考虑稳定性,所以只是升级到MySQL5.0的最后一个版本。

升级很简单,轻车熟路,一贯是我最懒人的做法:

1.由于想重新使用mysql的配置向导来配置my.ini所以,先将mysql的服务删除掉,命令行执行,mysqld-nt –remove即可。

2.不改变mysql的安装目录,因此,只需要将原来的安装目录改个名就行(权当备份了)

3.执行mysql安装程序,安装到之前的目录下。

4.执行mysql的配置向导,进行my.ini的配置。

5.手动打开my.ini,修改数据库文件储存目录变量“datadir”,修改为之前的数据库储存位置

6.重启mysql

升级操作就算完毕了,原来的帐号都可以继续使用,其他无须做什么改变。

回头再来看系统日志,发现一个很奇怪的现象,就是刚升级完启动mysql的时候那个错误是没有的,但改完数据库储存目录后再重启那个错误又出现了。

看来,这个错误本身应该还是来自于mysql数据库,而且只能是mysql自身的数据库(数据库名:mysql),

于是,关闭mysql。

尝试将旧的mysql系统数据库(数据库名为mysql),改成其他名字,将新的mysql默认的系统数据库copy过来。

同时将旧系统数据库内的user表文件(三个)都覆盖到新系统数据库内。

这时候再启动mysql就不会有错误提示了。

查看了一下旧系统数据库表,发现其中一个数据表(mysql\func)里存在一条记录:

mysql> select * from func;
+-------+-----+---------+----------+
| name  | ret | dl      | type     |
+-------+-----+---------+----------+
| baker |   0 | udf.dll | function |
+-------+-----+---------+----------+
1 row in set (0.00 sec)

挺有意思的,真的不知道这是干什么用的,似乎没有它也一样正常运行。

结论:如果有类似这样错误的,可以尝试找一下系统数据库(mysql)的func表,把dl=udf.dll的这条记录删除掉,然后再重启mysql应该就可以了,如果怕出问题可以提前进行一下备份。

PS:网上其他的解决方案真的不知道是否可行,反正我是没成功。我的这个方案只是清除掉错误(功能),可能未必是一个完美的解决方案。但就个人而言,utf.dll似乎真的没什么用,删了也无所谓。

Foxmail无法发送邮件的解决办法

一直以来在客户端收发邮件都是使用Foxmail,用着比较舒服。目前还在使用6.5版的,虽然也装了7.0但还未使用,准备换操作系统后用。

最近用foxmail发邮件总失败,开始是用sohu的邮箱有问题,以为是连接SMTP服务器的问题或者foxmail设置有问题,搞了很久也不行,于是试图尝试给sohu邮箱客服发了纸条,结果,TMD,很久也没回复。

原本想放弃了的。

但今天试图用使用gmail发送邮件,竟然也不行,于是考虑,应该还是foxmail自身的问题。

想起来收邮件时有问题可以对收件箱进行一致性检查或者进行压缩。

于是尝试,对foxmail的发件箱->右键->属性,选择“压缩”,然后再检查“一致性”,一般这样做就可以正常发邮件了,如果还不行的话,再重复一遍这个操作,然后选择“工具”选项卡,点击“开始修复”,应该可以解决问题。

这个办法,仅针对你的foxmail的发信SMTP确定设置正确的情况下,才有效的,假如你的smtp本身设置就有问题那打死也发不了的,呵呵。

最明显的表征就是,明明昨天还可以发邮件,然后今天多次尝试怎么都发不了,那么估计就是你的发件箱出了问题,用我上面的办法就可以解决^_^

PHP在Windows下的安装

很久没在IIS6配置PHP了。因为服务器重装系统,今天配置了PHP。

我不习惯将PHP文件copy到系统目录内(system32),会导致日后升级比较麻烦。

PHP在IIS6下安装很简单,主要是读取指定的php.ini文件路径的设置问题。

我是通过注册表的IniFilePath来定义的,可以将下面的代码另存一个.reg文件,然后导入到注册表内。记得将C:\\PHP5改为实际的PHP存放目录。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\php]
"IniFilePath"="C:\\php5"

另外,一定要将PHP存放路径加入到系统环境变量Path里面去。否则会导致无法加载dll扩展的情况发生。这一步我就给忘了,结果启动iis的时候总会弹出一个类似如下的警告:

弹出应用程序: Warning: PHP Startup: Unable to load dynamic library '*****\php_curl.dll' - 找不到指定的模块。

 

MySQL5.0升级到5.5

服务器又出故障了,这次比较彻底——系统文件丢失:(

不得已重做了系统。

趁着这个重做系统,决定将MySQL自5.0升级到5.5。 更多 »

Windows2003计划任务实现服务器自动重启

最近服务器刚刚更换了一块新硬盘,同时也将PHP升级了一下,然后不知道什么原因(因为这两个维护导致的或是其他的)IIS运行PHP的站点每隔一阵就会无法访问,而静态页面的站点是可以访问的,最为奇怪的是,貌似每次发生这样的故障的间隔期间基本是差不多的,尝试检查了一下,没发现什么意外情况,连系统的日志以及IIS自身的日志都没有什么异常记录。同时也是比较懒得详细检查,所以干脆直接搞了定时重启服务器。

这绝对是一个非常非常非常懒惰的行为,可确实是没什么更好的办法了,如果有朋友能知道这是怎么个原因的话不妨告诉一下,千恩万谢!!! 更多 »

关于WinXP/Win2003系统时间同步间隔的设置

有时候会发现Win2003系统日志内有一些来源为:W32Time,事件ID为:36,事件描述为:

时间服务有 86400 秒没有与系统时间同步,因为没有一个时间服务提供程序 提供可用的时间戳。时间服务将不再是同步的,也不能为其它客户端提供 时间或者更新系统时钟。请查看事件查看器中显示的系统事件,以确认没 有发生更严重的问题。

这是一个警告事件。 更多 »

关于“找不到附属汇编 Microsoft.VC90.CRT,上一个错误是 参照的汇编没有安装在系统上。”的解决

一个项目需要在Win系统用计划任务执行PHP,写了个批处理bat利用php-cgi.exe进行执行PHP文件,由于在服务器运行为了不影响服务器既有的PHP配置信息,同时也是考虑未来的移植性还有性能问题,自己弄了个精简了的PHP运行环境。

可在Win下死活也是执行不了,运行批处理直接闪一下就啥都木有咧,于是为了看具体的状态,使用cmd命令行模式去运行批处理文件,结果提示“系统无法执行指定的程序。”,悲催了,难道朋友将服务器给阉割导致不能执行.bat文件?

正咬牙切齿的时候决定再尝试一下确定到底是什么问题。这一次直接在cmd中执行php,运行php.exe -c php.ini -i(指定同php.exe相同目录下的php.ini作为php的配置文件,并且显示phpinfo信息),回车后,竟然还是那句该死的“系统无法执行指定的程序。”,看来不是系统运行不了bat批处理,是干脆不能执行php.exe,咋回事捏?
更多 »

由服务器想到的……

昨天夜里到今天上午,服务器由于第二块硬盘无法找到而停止运行。搞得心神不宁的……

服务器已经3年多了,头一两年基本比较稳定,自从去年来,频繁死机,先是更换过内存条,然后春节前有更换了主板,虽然最近一个多月温度稍微高一些(CPU温度一般在55到59度之间),但也算比较稳定的运行了40天,前天正庆幸机器争气,结果昨天就出现了意外——第二块硬盘偶尔就找不到了:(由于数据库以及一些系统日志文件都写到了第二块硬盘,因此非常害怕出问题,经过检查发现,似乎硬盘没什么问题,很有可能是数据线或者接口的问题。凌晨的时候机房没人,所以到今天早上给机房打电话帮忙查看一下,因为机房也没有备用的数据线,所以只是更换了一个插口,恢复开机后,发现运行稳定,暂时处于观察期,但也不敢大意,先把数据库进行了备份,然后将系统日志都转移到主硬盘上了,数据库还是留在那块上,期望减少对这块硬盘的请求降低它的负载,期望不会再有问题了。唉,每次服务器有问题都会搞得头痛,类似那种偏头痛的感觉,睡觉也不踏实,神经衰弱……

经过这个事情,目前考虑了一个新的架构。主要是针对投入有限的情况而且有期望性能有所提高的。

之前架构服务器的时候,为了节省资金获得最高的性价比,因此只用一台服务器进行架构,web+database,从数据库读写性能角度考虑,把数据库放到了第二块硬盘上,web服务和文件放在第一块硬盘(主硬盘) ,系统运行日志也放到第二块上了。其实这种架构应该说是最节省也是相对获得最大的性价比的方式,毕竟再花万把块钱实在是捉襟见肘了。不过,这次感觉这样的架构还是有点麻烦,数据库和系统日志都是频繁进行读写的,增加了系统的不稳定性,现在硬盘价格已经很便宜了,因此,考虑如果只用一台服务器架构web的话:

可以考虑将主硬盘只做操作系统、软件环境、然后单独划出一个分区作为整个系统的日志区,

第二块硬盘,作为web程序文件存放区,除此之外不再放其他文件。

第三块硬盘,作为数据库储存区,只放数据库文件。数据库日志不在此处,单独放到主硬盘的日志区内。

如果,还有可能的话,可以再加一块硬盘,单独作为备份盘使用,平时不做任何读写操作,纯粹做为数据库备份之用。

这样的架构,可以最大的降低磁盘磁头的读写频率,提高I/O性能,从而保护磁盘寿命。

PS:纯粹只是一台机器用的,如果有很多money,基本不太考虑这个了……穷啊……而且,这个服务器上的网站纯粹只是个人爱好而已,没有获得什么收入, 每年运行的费用虽然不多,可也不是个小数了……

百度和Google到底区别在哪里?

自打刚回到家里就感冒,这两天终于好了一些,现在已经不难受了,呆在家里整天看电视、看电影,要么就是研究一些无聊的东西。

最近一个实验站流量不错,自打服务器稳定后、域名更换为.com后,流量在慢慢的上升,甚至已经超过了另外的运行接近4年的小论坛。觉得很有意思,因为是实验目的比较大的,所以这几天也在琢磨原因。

有几个小发现:

1。服务器稳定性对于搜索引擎有影响,但未必是绝对的,当然前提是服务器不能长久(比如1个星期,呵呵)无法访问。这个影响最少应该不在收录,可能对于排名有点干扰。但只要网站内容独特,那么稳定后也一般可以恢复正常;

2。实验证明,.com效果要好于.cn。这个之前已经在很多运营交流站内被讨论过。无论Google还是百度,似乎都更偏好于.com(当然,我是指同等条件下的)。

3。百度更倾向实用性,Google更倾向技术性。这个无关谁强大或者谁更人性化。

看流量统计发现一个有趣的现象。

我的博客来自Google的占到接近95%的流量,百度仅仅为不到3%,甚至可能还不如Bing高。而我的另外一个站(生活内容为主)来自百度的接近 70%,Google约为20%。也许真的印证了一些做SEO的人的话:使用Google的多为做技术的,使用百度的多为非技术的……

只是一个无聊想想而已,我自己觉得,如果想做网站运营,那么就要脚踏实地的做好基础性的东西,比如结构、性能等等,慢慢的去积累内容,终究会有好看的流量的……

题外话,草根现在做网站运营真的越来越难了,难道ZF故意的……

回家啦

之前预计近期事情不多,加之与老妈一同回家,也为了错开春运高峰,所以提早买票回家。车票倒也还算比较顺利买到(早上4点就去车站排队)。可服务器突然罢工,主板和风扇都无法继续坚持,临走的前两天服务器疯狂死机,最后没办法重新更换主板和风扇,虽然买的时候颇费一番折腾,但快递到机房速度很快,机房更换的速度也挺快也很顺利,悬着得心终于放松下来。安心的上火车回家。

29号到家,30号恢复宽带,回来后就观察网站流量,发现服务器死机对于网站的流量和搜索引擎的影响都不大(至少目前为止) 。

昨天早上发现服务器流量异常,比平时正常的流量高出很多,但CPU无明显的攀高,查询日志发现某个来自台湾的IP段(根据IP来源显示是台湾)频繁访问服务器的静态文件,发出的协议是“Java/1.4.2_07” ,判断肯定不是搜索引擎也不是正常的访客,因此果断屏蔽整个该IP段,服务器流量一下恢复正常。

也许是前一阵折腾的上火,加上旅途的折腾,回来就开始不舒服,今天开始咳嗽、流鼻涕了,喝了水吃了药,今天早点睡,希望感冒尽快好,还有很多事要做:(

回家真好,虽然外面很冷,但屋里非常温暖。听老爸说家附近一个地方被列为文物保护点 ,等感冒好利索,让老爸导游”游览“一番,呵呵。

热炕头、冻梨、冰激凌、最爱吃的炖豆腐……该死的感冒……等好了通通补回来^_^

HTTP协议的那些事儿

什么是http连接?一张页面加载过程中,又是图片又是样式、脚本,对于这些东西的请求,是共用一个连接还是多个连接?
网上有人说,为了节省连接数,应该尽量将外部CSS,js合并,或者内联;甚至图片也合成一张,再用CSS定位。显然,在这里,一个请求就用一个连接,请求完成连接即被关掉。
但IIS里,有选项“保持HTTP连接”,且有超时时间可供设置。如果每请求一样东西,就开启一个连接,并且这个连接迟迟不死,保持激活,那么要多少连接才够用?这里的意思,应该是一个连接可以供多次使用。

更多 »

常用HTTP状态代码和解释说明

来自 Google 的一篇帮助内容,略有修改。

如果向您的服务器发出了某项请求要求显示您网站上的某个网页,那么,您的服务器会返回 HTTP 状态代码以响应该请求。此状态代码提供了有关请求状态的信息,且为请求方提供了有关您网站和请求的网页的信息。

一些常见的状态代码为:

  • 200 – 服务器成功返回网页
  • 404 – 请求的网页不存在
  • 503 – 服务器暂时不可用

以下提供了 HTTP 状态代码的完整列表。点击链接可了解详细信息。您也可以访问有关 HTTP 状态代码的 W3C 页来了解详细信息更多 »

Deepseath Modified from Green Hope Theme · Proudly powered by WordPress · 津ICP备09005418号  津公网安备 12010302001005号