<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>达达&#039;s Blog &#187; Linux</title>
	<atom:link href="http://www.isdada.com/category/appdev/linux-codedev/feed" rel="self" type="application/rss+xml" />
	<link>http://www.isdada.com</link>
	<description></description>
	<lastBuildDate>Mon, 30 Aug 2010 13:00:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>一场域名引发的血案</title>
		<link>http://www.isdada.com/a-strange-question-cause-by-domain.html</link>
		<comments>http://www.isdada.com/a-strange-question-cause-by-domain.html#comments</comments>
		<pubDate>Sun, 25 Jul 2010 12:34:03 +0000</pubDate>
		<dc:creator>达达</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[499]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[domain]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[Ubuntu]]></category>

		<guid isPermaLink="false">http://www.isdada.com/?p=1752</guid>
		<description><![CDATA[07/27Update:26日晚上新的域名再次挂掉。终于找到了原因，因为新域名正在备*案，被那个叫做未*备*案域*名*过*滤*系*统给拦截掉了。好吧，老老实实备案去。 这件血案真的是不堪回首，整整花了我们5天时间，导致了项目严重延期。 7月16日。晚上发现服务器上有个网站经常性出现了打不开的情况，查看了cacti，服务器的负载和网络都非常正常，调高了php的timeout，以为没多少问题了。事实是自己刷新也没问题了。 7月17日，问题大爆发了，服务器上另外一个网站也大规模出现了此问题，但非常奇怪的是，还有两个网站是没问题的。从此拉开了纠结的5天难熬的时间的序幕。服务器后端是使用apache的，然后采用nginx做反向代理。调高了nginx的缓存和timeout，都基本无效。但是非常奇怪的是，使用相同配置的另外两个网站是一点问题都没，啥都正常。 查看了日志，nginx中大量出现499错误。google了一下，是“client has closed connection”的nginx自定义错误。但很奇怪的是，使用apache的端口去访问却是一切正常，因此，初步判定是nginx的问题，好吧，既然是nginx问题，那就研究这玩意儿，调配置、换Development版本的nginx都无效，陷入无头绪状态。有点怀疑是域名问题了，此时用hosts绑定了一个域名上去，刷刷是正常的。 7月18日，绝对废掉nginx，直接用apache上，刚开始好好的，后来发现又不行了。日志中status 是200 ，但返回的是0字节。这个就纠结了。根据这个可能有人会问了，是不是因为我代码的问题，其实我判断不是。因为使用如下代码都经常性地刷不出来 &#60;?php echo "hi"; sleep(3); echo "dada"; ?&#62; 非常纠结。 7月19日，此时有点怀疑是PHP的问题，但排查了之后发现不是。换上nginx+fastcgi同样的问题。还好，公司里还有一台服务器。装上了Ubuntu以及其他必须的软件，在局域网内怎么刷都没有问题。 7月20日，把公司里的服务器上架到机房，发现老域名刚开始好好的，但一下子又老问题重现了，整套环境都换了，因此肯定不是我们的问题了。域名是godaddy上注册了，dns转换是用dnspod的。很有可能是DNSPOD问题，也很有可能是域名被XXX盯上了（事实证明不是，因为被盯上的话是被重置）。 7月21日，换了新域名后，一切正常的。到今天为止，一切正常。 其实到今天还是不思其解。。。 莫非真的是域名问题，还是DNSPOD引起的？？？ 话说nginx+fastcgi真是好用，性能杠杠的！]]></description>
			<content:encoded><![CDATA[<p><span style="color: #ff6600;">07/27Update:26日晚上新的域名再次挂掉。终于找到了原因，因为新域名正在备*案，被那个叫做未*备*案域*名*过*滤*系*统给拦截掉了。好吧，老老实实备案去。</span></p>
<p>这件血案真的是不堪回首，整整花了我们5天时间，导致了项目严重延期。</p>
<p>7月16日。晚上发现服务器上有个网站经常性出现了打不开的情况，查看了cacti，服务器的负载和网络都非常正常，调高了php的timeout，以为没多少问题了。事实是自己刷新也没问题了。</p>
<p>7月17日，问题大爆发了，服务器上另外一个网站也大规模出现了此问题，但非常奇怪的是，还有两个网站是没问题的。从此拉开了纠结的5天难熬的时间的序幕。服务器后端是使用apache的，然后采用nginx做反向代理。调高了nginx的缓存和timeout，都基本无效。但是非常奇怪的是，使用相同配置的另外两个网站是一点问题都没，啥都正常。</p>
<p>查看了日志，nginx中大量出现499错误。google了一下，是“client has closed connection”的nginx自定义错误。但很奇怪的是，使用apache的端口去访问却是一切正常，因此，初步判定是nginx的问题，好吧，既然是nginx问题，那就研究这玩意儿，调配置、换Development版本的nginx都无效，陷入无头绪状态。有点怀疑是域名问题了，此时用hosts绑定了一个域名上去，刷刷是正常的。</p>
<p>7月18日，绝对废掉nginx，直接用apache上，刚开始好好的，后来发现又不行了。日志中status 是200 ，但返回的是0字节。这个就纠结了。根据这个可能有人会问了，是不是因为我代码的问题，其实我判断不是。因为使用如下代码都经常性地刷不出来</p>
<pre lang="php">&lt;?php
 echo "hi";
 sleep(3);
 echo "dada";
 ?&gt;</pre>
<p>非常纠结。</p>
<p>7月19日，此时有点怀疑是PHP的问题，但排查了之后发现不是。换上nginx+fastcgi同样的问题。还好，公司里还有一台服务器。装上了Ubuntu以及其他必须的软件，在局域网内怎么刷都没有问题。</p>
<p>7月20日，把公司里的服务器上架到机房，发现老域名刚开始好好的，但一下子又老问题重现了，整套环境都换了，因此肯定不是我们的问题了。域名是godaddy上注册了，dns转换是用dnspod的。很有可能是DNSPOD问题，也很有可能是域名被XXX盯上了（事实证明不是，因为被盯上的话是被重置）。</p>
<p>7月21日，换了新域名后，一切正常的。到今天为止，一切正常。</p>
<p>其实到今天还是不思其解。。。</p>
<p>莫非真的是域名问题，还是DNSPOD引起的？？？</p>
<p>话说nginx+fastcgi真是好用，性能杠杠的！</p>
]]></content:encoded>
			<wfw:commentRss>http://www.isdada.com/a-strange-question-cause-by-domain.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>因nginx无法完整下载文件的错误分析</title>
		<link>http://www.isdada.com/can-not-download-big-file-cause-by-nginx.html</link>
		<comments>http://www.isdada.com/can-not-download-big-file-cause-by-nginx.html#comments</comments>
		<pubDate>Mon, 31 May 2010 03:05:50 +0000</pubDate>
		<dc:creator>达达</dc:creator>
				<category><![CDATA[Linux]]></category>

		<guid isPermaLink="false">http://www.isdada.com/?p=1737</guid>
		<description><![CDATA[上周四下午开始，突然发生了这样的情况，在Discuz中无法下载大文件，大约大于100K以上的文件都无法下载，下载到30~70K的时候就不动了。修改了attachments.php中的几个值都无效。很纳闷，写了PHP文件测试，也同样发现了这样的情况，于是肯定不是Discuz的问题。 Google一下，根据建议修改了PHP的几个值，也无效，顿时内牛满面。 然后便排查apache的设置，又修改，仍然无效。。。 WW了一下明城同学 ，果然是牛人，建议我查看一下nginx的设置，因为服务器是nginx反向代理到apache的。修改了配置文件，加大了以下的值 proxy_buffer_size 16k; proxy_buffers 16 128k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; 完美解决此问题，同时没有其他后遗症]]></description>
			<content:encoded><![CDATA[<p>上周四下午开始，突然发生了这样的情况，在Discuz中无法下载大文件，大约大于100K以上的文件都无法下载，下载到30~70K的时候就不动了。修改了attachments.php中的几个值都无效。很纳闷，写了PHP文件测试，也同样发现了这样的情况，于是肯定不是Discuz的问题。<br />
Google一下，根据建议修改了PHP的几个值，也无效，顿时内牛满面。<br />
然后便排查apache的设置，又修改，仍然无效。。。<br />
WW了一下<a href="http://www.gracecode.com" target="_blank">明城</a>同学 ，果然是牛人，建议我查看一下nginx的设置，因为服务器是nginx反向代理到apache的。修改了配置文件，加大了以下的值</p>
<pre name="code">
proxy_buffer_size          16k;
proxy_buffers              16 128k;
proxy_busy_buffers_size    256k;
proxy_temp_file_write_size 256k;
</pre>
<p>完美解决此问题，同时没有其他后遗症</p>
]]></content:encoded>
			<wfw:commentRss>http://www.isdada.com/can-not-download-big-file-cause-by-nginx.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>rsync 的诡异小问题</title>
		<link>http://www.isdada.com/rsync_little_problem.html</link>
		<comments>http://www.isdada.com/rsync_little_problem.html#comments</comments>
		<pubDate>Tue, 22 Dec 2009 13:08:22 +0000</pubDate>
		<dc:creator>达达</dc:creator>
				<category><![CDATA[Linux]]></category>

		<guid isPermaLink="false">http://www.asflex.cn/?p=1406</guid>
		<description><![CDATA[rsync是linux下的一个网站同步的超强工具，这个不多介绍，搜索一下，一堆资料。 今天遇到了一个很诡异的问题，用户授权老是有问题。情况是这样的： 写好了/etc/rsyncd.conf里的模块 其中有这么一段： [testsite] path = /home/dada/sites/testsite/ ignore errors read only = true list = true auth users = dada secrets file = /etc/backserver.pas /etc/backserver.pas是授权用户的配置文件。内容如下 dada:123456 在备份主机上进行文件同步 sudo rsync -vzrtopg &#8211;delete &#8211;exclude &#8211;progress dada@192.168.1.107:: testsite /home/dada/backupsites/ 输入正确的密码仍然提示未授权。 查看了日志，也没发现特别特殊的信息。 后来终于查到了这个： http://www.sjle8.cn/redirect.php?fid=47&#38;tid=4666&#38;goto=nextnewset 果真是因为这个问题 sudo chmod -c 600 /etc/backserver.pas 解决问题！]]></description>
			<content:encoded><![CDATA[<p>rsync是linux下的一个网站同步的超强工具，这个不多介绍，搜索一下，一堆资料。</p>
<p>今天遇到了一个很诡异的问题，用户授权老是有问题。情况是这样的：</p>
<p>写好了/etc/rsyncd.conf里的模块<br />
其中有这么一段：<br />
<span style="background-color: #ffffff;"> </span></p>
<div id="_mcePaste">[testsite]</div>
<div id="_mcePaste">path = /home/dada/sites/testsite/</div>
<div id="_mcePaste">ignore errors</div>
<div id="_mcePaste">read only = true</div>
<div id="_mcePaste">list = true</div>
<div id="_mcePaste">auth users = dada</div>
<div id="_mcePaste">secrets file = /etc/backserver.pas</p>
<p>/etc/backserver.pas是授权用户的配置文件。内容如下</p></div>
<div>dada:123456</div>
<div></div>
<div>在备份主机上进行文件同步<br />
sudo rsync -vzrtopg &#8211;delete &#8211;exclude &#8211;progress dada@192.168.1.107::<span style="background-color: #ffffff;"> testsite </span>/home/dada/backupsites/</div>
<p>输入正确的密码仍然提示未授权。</p>
<p>查看了日志，也没发现特别特殊的信息。</p>
<p>后来终于查到了这个：</p>
<p><a href="http://www.sjle8.cn/redirect.php?fid=47&amp;tid=4666&amp;goto=nextnewset">http://www.sjle8.cn/redirect.php?fid=47&amp;tid=4666&amp;goto=nextnewset</a></p>
<p>果真是因为这个问题</p>
<p>sudo chmod -c 600 /etc/backserver.pas</p>
<p>解决问题！</p>
]]></content:encoded>
			<wfw:commentRss>http://www.isdada.com/rsync_little_problem.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
