月度归档： 2017 年 2 月

Ubuntu 14.04上卸载nginx之后重新安装没有重新生成配置文件的解决方法

在配置nginx做实验时配置错了，导致访问不了虚拟主机。一狠心把nginx的配置文件目录(/etc/nginx)都删除了，而且我没有备份这些配置文件，因此想重装nginx。

本来以为直接使用如下apt-get指令

$ sudo apt-get --purge remove nginx
$ sudo apt-get install nginx

就可以搞定，但实际上并没有有自动产生nginx的配置文件，连/etc/nginx目录都没产生。
于是autoremove

$ sudo apt-get --purge remove nginx
$ sudo apt-get autoremove
$ sudo apt-get install nginx

提示

awk: cannot open /etc/nginx/nginx.conf (No such file or directory)

虽然产生了/etc/nginx目录了，但只有部分配置文件

conf.d sites-available sites-enabled

于是

$ sudo apt-get --purge remove nginx
$ sudo apt-get autoremove
$ dpkg --get-selections | grep nginx

罗列出与nginx相关的软件

nginx-common

然后卸载并重新安装

$ sudo apt-get --purge remove nginx-common
$ sudo apt-get install nginx

参考链接

nginx配置失败，卸载后重装出问题 awk: cannot open /etc/nginx/nginx.conf (No such file or directory)，nginxawk

Windows 7 下无法查看DebugView的解决方案

在Windows 7中开程序的人来说，也许会发现DebugView在Win7中无法查看OutputDebugString所抛出的消息，
这对像Timer或者是连续发生的（Event）事件（比如：OnPaint或Mouse移动等Event）进行DEBUG非常不方
便，也许这是微软为了安全原因考虑，所以把此功能给关闭。
※如果要打开此功能，请依照如下步骤进行：
1.打开注册表（在Run -> regedit）。
2.打开这个键：[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]。
3.建立[Debug Print Filter]这个新键。
4.新增加一个“DEFAULT”的DWORD值，将其内容设置0x0f，如下图所示：
5.重启OS后生效。

这样以后你就可以使用OutputDebugString来输出信息了。

图方便的话，直接下载注册表文件 OutputDebugString 下载并解压缩后，双击导入即可。

参考链接

Win7下无法查看DebugView的解决方案

解决国内访问s3.amazonaws.com下载文件非常缓慢的问题

今天，尝试从 https://git-for-windows.github.io/ 更新msysgit到最新版本的时候，发现下载链接 https://github.com/git-for-windows/git/releases/download/v2.12.0.windows.1/Git-2.12.0-64-bit.exe被服务器重新定向到了亚马逊的服务器上去了，最后的下载地址是github-cloud.s3.amazonaws.com的某台机器上。但是国内访问亚马逊，基本上没办法下载成功的，很可能是被墙了。
搜索了一下，发现可以通过设置host,强制把访问节点从美国定向到香港的办法来解决这个问题。Windows下，编辑C:\Windows\System32\drivers\etc\hosts然后增加如下解析即可。

219.76.4.4 s3.amazonaws.com
219.76.4.4 github-cloud.s3.amazonaws.com

对于Linux以及macOS，则修改/etc/hosts。

参考链接

github release 的github-cloud.s3.amazonaws.com实在太慢，下载老在10几k徘徊

TortoiseGit 2.4.0.2引入了一个新的BUG，导致无法提交，提示“fatal: protocol error: bad line length character: Welc”

今天（2017.02.27）TortoiseGit 2.4.0发布了一个Hotfix来修正几个BUG,网站上的具体的版本信息如下：

2017-02-25 | Released TortoiseGit Hotfix 2.4.0.2 (fixes issue #2909 (Commit dialog unclosable) and issue #2911 (Add returns "invalid path") and contains PuTTY 0.68)

但是这次的修复引入了更大的BUG,导致无法提交代码，不管是拉取还是提交代码，都会提示"fatal: protocol error: bad line length character: Welc",如下图：

修复这个问题最简单的方法就是还原到TortoiseGit 2.4.0版本。

这个BUG是由TortoiseGitPlink.exe里面的代码改动引起的，只要还原这个文件到0.67版本（来自TortoiseGit 2.4.0），也可以解决这个问题。

目前已经提交了BUG给开发人员了。对于的BUG链接地址如下：
TortoiseGit 2.4.0.2 bug ( TortoiseGit 2.4.0 works but TortoiseGit 2.4.0.2 can not pull and push) "fatal: protocol error: bad line length character: Welc"

希望能尽快修复这个问题吧！

到目前为止（2017.05.09）这个问题依旧没有修复的可能，因此建议大家可以改用一下SourceTree-2.0.20.1,可以点击这里下载目前最新的版本。

mac下~/.bashrc不起作用

～/.bashrc里面的一些设置，比如alias命令的设置“不起作用”，新开一个终端都要source一下才起作用。

unix下当shell是login shell，.bash_profile才会加载，而bashrc正好相反。

真正的区别是在linux下，当用户登录到一个图形界面，然后打开一个终端terminal，那些shell是non-login shell。

然而，在OS X登录的时候，并没有运行着一个shell，所以，在运行Terminal.app的时候，其实那是一个login shell。

后来新建了.bash_profile加载一次.bashrc.

if [ "${BASH-no}" != "no" ]; then
    [ -r ~/.bashrc ] && . ~/.bashrc
fi

参考链接

mac下~/.bashrc不起作用

Jdom-XmlOutputter 换行(setIndent)

Jdom的XmlOutputter默认生成的文件不带换行，所有key-value对写在一行里，使用起来很不方便，XmlOutputter支持设置换行。

jdom1.0中写法如下

XmlOutputter xmlOut = new XmlOutputter("  ", true, "utf-8");

三个参数分别为，缩进（这里是两个空格），是否换行，字符编码

官方文档

jdom1.0以后不支持上面的写法，而是把三个参数剥离出来，形成了Format类

Format format = Format.getCompactFormat();
format.setEncoding("utf-8");
format.setIndent("  ");
XMLOutputter XMLOut = new XMLOutputter(format);

Ubuntu 14.04.5版本上安装并启用Apache 2.4.10版本的Event MPM模块

Apache 2.4版本开始已经尝试借鉴Nginx的实现方式来处理网络连接。但是到目前（2017.2.22）为止，实现的并不彻底，只是在处理HTTP协议的时候使用异步模式，而处理HTTPS协议的时候，依旧使用每个连接一个线程的模式。据说完整的支持HTTPS异步，要到Apache 3.x版本了。

目前的Apache MPM event本质上还是Apache MPM worker的优化版本，并不是一个完整的独立模式。

尽管支持的不是太完善，但是这部分的实现，已经能比较好的改善Apache 2.4的网络处理性能了，尤其是对于我这种访问压力不是太大的网站来说，目前应该是够用了的。暂时可以缓解一下迁移到Nginx的急迫性，并且比较好的减少访问网站时候的延迟比较高的问题。

到目前（2017.2.22）为止在Ubuntu 14.04.5版本上Apache Event MPM还不属于正式版本，而是被部署到了backports(待发布)分支上，处于候选发布状态，因此我们安装的时候，需要执行指定backports，具体执行命令如下：

$ sudo apt-get -t trusty-backports install apache2-mpm-event

模块的配置文件在/etc/apache2/mods-available/mpm_event.conf,目前我这边用默认配置已经足够了（足见访问量是多么的少，呵呵）。

启用Apache MPM event模块

$ sudo a2dismod mpm_worker

$ sudo a2dismod mpm_prefork

$ sudo a2enmod mpm_event

$ sudo service apache2 restart

查询Apache 2.4当前正在使用的模块

$ a2query -M

返回值会是event, prefork, worker中的一个，如果返回了event，则说明我们已经成功启用了Apache MPM event模块。

目前实际测试来看，确实能非常明显的加快网站的访问速度，访问延迟明显变短。

参考链接

Ubuntu 14.04系统上使用Apache2.4.10+PHP5+FastCGI的WordPress网站大量php5-cgi defunct引起网站访问异常缓慢

最近网站访问异常缓慢，网站响应时间明显延迟很多，观察系统的处理器占用，一点都不高，带宽也在合理范围之内，因此分析Apache-2.4.10的错误日志

$ cat /var/log/apache2/error.log

发现大量的出现

[Tue Feb 21 21:16:12.012511 2017] [fcgid:warn] [pid 19442:tid 140638402033408] [client 54.147.162.12:50579] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: https://www.google.com/

如下图：

感觉很奇怪，于是看了一下php相关的进程，执行命令

$ ps -A | grep php

执行结果如下图：

发现大量的php5-cgi进程处于defunct状态（僵尸状态），导致达到了进程数量的限制上限，无法继续提供服务。

但是上面的日志，是已经出现问题的时候的日志，既然进程不足了，自然无法提供服务了，继续向上追踪，发现大量的进程崩溃日志

[Mon Feb 20 18:07:12.857016 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 15291 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:12.857024 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 15408 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:12.857031 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 17723 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:14.859108 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 16387 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:14.859170 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 15291 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:14.859178 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 15408 still did not exit, sending a SIGTERM
[Mon Feb 20 18:07:14.859185 2017] [core:warn] [pid 15284:tid 139855916136320] AH00045: child process 17723 still did not exit, sending a SIGTERM

感觉很奇怪，最初以为是由于调整Apache-2.4.10服务器，多次在正常运行中重启服务器，导致正在服务的php5-cgi进程变成了僵尸进程。但是重启服务器之后，过了几天后，问题依旧发生了。

于是网上搜索了一下，感觉应该更像是PHP-CGI进程本身存在内存泄漏问题，导致进程长时间执行之后，由于资源开销问题导致进程崩溃。

目前我的服务器上启用的是Apache2的Event MPM模块,查看其中的配置文件：

$ cat /etc/apache2/mods-enabled/mpm_event.conf

可以看到里面的内容如下：

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves
<IfModule mpm_event_module>
	StartServers			 2
	MinSpareThreads		 25
	MaxSpareThreads		 75
	ThreadLimit			 64
	ThreadsPerChild		 25
	MaxRequestWorkers	  150
	MaxConnectionsPerChild   0
</IfModule>

发现，设置MaxConnectionsPerChild参数为0,根据 Apache MPM Common Directives 里面的介绍，这个参数的作用就是一个进程处理多少个请求后就退出。而如果设置了 0 则代表，除非出现了异常，否则进程会一直存在。这样的话，一旦资源泄漏，进程就会各种异常了。因此需要设置一下这个参数，一般这个参数设置为1000-5000左右，根据实际情况自己调整一下参数。注意：这个参数的设置是会影响到网站的访问速度的，尤其是当服务器的连接次数到达限制的时候，此时大量的服务器进程都在重启，导致此时的访问要么被重置要么耗时变的非常长。因此，如果没有资源泄漏的话，可以不设置这个限制。

注意一下这个介绍的最后一句话，讲的就是这个参数可以修正资源泄漏问题，如下：

Setting MaxConnectionsPerChild to a non-zero value limits the amount of memory that process can consume by (accidental) memory leakage.

修改参数后，需要重启服务生效。

按照上面的方法实现后，过了一个礼拜后，这个现象再次发生了。

观察了一下Apache2当前已经启用的模块

$ ls /etc/apache2/mods-enabled/

发现，由于是从Apache2.2升级到的Apache2.4，或许是某次的配置，导致fastcgi与fcgi两个模块同时被启用了。

是不是两个相同功能的模块同时启用导致功能冲突了呢？

先尝试禁用fastcgi(这个模块已经被fcgi替换了).

$ a2dismod fastcgi

$ service apache2 restart

目前看来，问题依旧发生了！！！

查看Apache2中的FastCGI的配置信息

$ vim /etc/apache2/mods-enabled/fcgid.conf

可以看到如下内容

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi .php
  FcgidConnectTimeout 120
  DefaultMaxClassProcessCount 10
  MaxRequestLen  157286400
  IPCCommTimeout 300
</IfModule>

其中的AddHandler中的.php引起了注意，因为在日志中出现问题之前一直会出现如下的错误日志：

[Tue Feb 21 01:56:12.876460 2017] [fcgid:warn] [pid 21582:tid 140134271887104] [client 114.82.132.78:2410] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/90sec.php
[Tue Feb 21 01:56:16.727715 2017] [fcgid:warn] [pid 20546:tid 140134255101696] [client 114.82.132.78:2647] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/spider.php
[Tue Feb 21 01:56:20.434429 2017] [fcgid:warn] [pid 21582:tid 140134263494400] [client 114.82.132.78:3049] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/e7xue.php
[Tue Feb 21 01:56:35.130495 2017] [fcgid:warn] [pid 20546:tid 140134297065216] [client 114.82.132.78:3446] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/x.php
[Tue Feb 21 01:56:38.668792 2017] [fcgid:warn] [pid 20546:tid 140134238316288] [client 114.82.132.78:3985] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/service.php
[Tue Feb 21 01:56:42.247574 2017] [fcgid:warn] [pid 22275:tid 140134263494400] [client 114.82.132.78:4368] mod_fcgid: can't apply process slot for /usr/bin/php5-cgi, referer: http://www.mobibrw.com/plus/av.php

而这个配置项是从Ubuntu 12.04中手工引入的，我们尝试去掉这个。另外，可以看到

DefaultMaxClassProcessCount 10

也就是FastCGI的最大进程数是被设置成了10,但是，我这边限制PHP-FPM的最大进程数为5，是不是FastCGI的进程数如果大于PHP-FPM能够提供服务的数量的时候，会导致FastCGI进程出现僵尸状态呢？ 是不是这个原因导致的呢？ 于是修改后的结果如下：

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 120
  DefaultMaxClassProcessCount 5
  MaxRequestLen  157286400
  IPCCommTimeout 300
</IfModule>

经过这几天的观察，貌似现象不再出现了，这个应该是Apache 2.4版本引入的BUG,以前的配置的Apache 2.2版本上是没有任何问题的，究竟原因是mod_fcgid无法处理.php格式的脚本导致，还是由于mod_fcgid进程数高于php-fpm的进程数导致mod_fcgid进程长时间无法获取到可用的php-fpm连接，导致进程被饿死，这个暂时不详细追究了。

今天在修改配置的时候，由于配置错误，导致PHP-FPM服务无法正常启动，但是整个服务器竟然一直可以正常访问，那么结论就是Apache 2.4在当前的配置下，根本就没有使用PHP-FPM模式进行通信，而是使用标准的FastCGI的方式调度的。
于是网上搜索半天，结合自己的尝试，找到了根本原因：

<Directory /var/www/wordpress>
		#Options Indexes FollowSymLinks MultiViews
		Options FollowSymLinks MultiViews
		AllowOverride All
		FCGIWrapper /usr/bin/php5-cgi .php
		AddHandler fcgid-script .php
		Options ExecCGI SymLinksIfOwnerMatch
		Order allow,deny
		allow from all
</Directory>

上面的配置在Apache 2.2版本上是不影响后面启用的PHP-FPM配置的，对于PHP的请求，最终都是定向到PHP-FPM的。但是相同的配置在Apache 2.4上面，则被定向到了FastCGI上面。因此修改方式如下(至少要高于2.4.10，否则配置无效)：

<Directory /var/www/wordpress>
		#Options Indexes FollowSymLinks MultiViews
		Options FollowSymLinks MultiViews
		AllowOverride All
#		Apache 2.2/2.4.9
#		FCGIWrapper /usr/bin/php5-cgi .php
#		AddHandler fcgid-script .php
#		Options ExecCGI SymLinksIfOwnerMatch
#		Apache 2.4.10
		<FilesMatch \.php$>
			SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost"
		</FilesMatch>	
		Order allow,deny
		allow from all
</Directory>

至此，应该才是从根本上解决了服务器上的问题。

开始的时候忽略了一个基础的问题，那就是php5-cgi跟php5-fpm进程本身就不应该同时存在，如果服务器使用php5-fpm，那么php5-cgi的进程就不应该被调用，这个问题没有重视，导致了整个问题分析时间冗长，反复。

本质上是服务器的配置错误导致问题。

Ubuntu 14.04上的Apache服务器限制单个用户的下载带宽

今天突然发现自己的服务器访问异常缓慢，从阿里云的监控平台上看到，CPU的利用率并不高，但是带宽却已经被吃满了，导致网站访问异常缓慢，跟踪了一下发现是某个用户下载网站上的大文件导致了带宽吃紧的情况。因此需要限制某个用户的独占带宽。

具体操作

1.安装带宽限制模块

$ sudo apt-get install libapache2-mod-bw

2.启用模块

$ a2enmod bw

3.配置网站对于带宽的限制规则

$ sudo vim /etc/apache2/sites-enabled/000-default.conf

在原有的

<VirtualHost *:80>
...................
...................
</VirtualHost>

之间增加如下内容

# activate bandwidth limitation
BandwidthModule On
ForceBandWidthModule On
# * 表示文件类型，所有大于1000k的文件下载速度100k , 这里我当时以为两个单位一样的。。。
LargeFileLimit * 1000 100000
# 不限制单个用户的带宽占用
BandWidth all 0
# 每个IP地址建立的最大连接数量，由于NAT上网的存在，多用户可能同一个外网IP，因此这个数字不可太小
MaxConnection all 120

然后重启Apache2.

$ sudo service apache2 restart

注意，如果配置了HTTPS，那么对应的配置文件也需要调整。

参考链接

Ubuntu 14.04检查是谁占用了带宽

今天突然发现自己的服务器访问异常缓慢，从阿里云的监控平台上看到，CPU的利用率并不高，但是带宽却已经被吃满了，导致网站访问异常缓慢，于是想看看究竟是哪个连接导致的，网上搜索了一下，找到iftop工具。
安装如下：

$ sudo apt-get install iftop

阿里云的ECS服务器上，外网网卡默认是eth1,因此执行如下命令：

$ sudo iftop -i eth1

可以看看是哪些连接长时间占用了带宽，然后去Apache2的访问日志中对应看看IP地址在访问哪些文件就知道具体情况了。

下面是原文照抄

利用iftop找出是谁占用了带宽

有时候我们的网络缓慢并不是由远程服务器或路由器所引起，而只是因为系统中的某些进程占用了太多可用带宽。虽然从直观角度我们很难确定哪些进程正在使用带宽，但也有一些工具能帮大家把这些捣蛋的家伙揪出来。

top就是这样一款出色的故障排查工具，它的出现还带来一系列思路相似的衍生品，例如iotop--能够确定到底是哪些进程占用了大部分磁盘I/O性能。最终名为iftop的工具横空出世，能够在网络连接领域提供同等功能。与top不同，iftop不会亲自关注进程情况，而是列出用户服务器与远程IP之间占用带宽最多的连接对象。举例来说，我们可以在iftop中快速查看备份服务器IP地址在输出结果中的位置来判断备份工作有没有大量占用网络带宽。

iftop输出图示

红帽与Debian的各个发行版都能使用iftop这一名称的软件包，但在红帽发行版方面大家可能需要从第三方资源库才能获取。一旦安装过程完成，我们在命令行中运行iftop命令即可启用（需要root权限）。和top命令一样，我们可以点Q键退出。

在iftop界面屏幕的最上方是显示全局流量的信息栏。信息栏之下则是另外两列信息，一列为源IP、另一列为目标IP，二者之间以箭头填充帮助我们了解带宽被用于从自己的主机向外发送数据还是从远程主机端接收数据。再往下则是另外三个栏位，表示两台主机之间在2秒、10秒及40秒中的数据传输速率。与平均负载相似，大家可以看到目前带宽使用是否达到峰值，或者在过去的哪个时段达到过峰值。在屏幕的最下方，我们会找到传输数据（简称TX）与接收数据（简称RX）的总体统计结果。与top差不多，iftop的界面也会定期更新。

在不添加额外参数的情况下，iftop命令通常能够满足我们故障排查的全部需求；但有的时候，我们可能也希望利用一些选项实现特殊功能。iftop命令在默认情况下会显示查找到的第一个端口的统计信息，但在某些服务器中大家可能会使用多个端口，所以如果我们希望让iftop打理第二个以太网端口（即实例中的eth1），那么请输入iftop -i eth1。

默认情况下，iftop会试图将所有IP地址通过解析转换为主机名称。这样做的缺点在于一旦远程DNS服务器速度缓慢，报告的生成速度也将随之惨不忍睹。另外，所有DNS解析活动都会增加额外的网络流量，而这些都会显示在iftop的报告界面当中。因此要禁用网络解析功能，别忘了在iftop命令后面加-n哦。

一般说来，iftop显示的是主机之间所使用的全局带宽；但为了帮助大家缩小排查范围，我们可能希望每台主机具体使用哪个端口进行通信。毕竟只要找到了主机中占用最大带宽的网络端口，我们就可以在判断是否接入FTP端口之外进行其它排查手段。启动iftop之后，按P键可以切换端口的显示与隐藏状态。不过大家可能会注意到，有时候显示所有端口状态可能导致我们正在关注的主机被挤出当前显示屏幕。如果出现这种情况，我们还可以按S或D键来仅显示来自特定源或特定目标的端口。由于服务项目众多，目标主机可能随机使用多个端口并发生带宽占用峰值，这将导致工具无法识别出正在使用的服务，因此仅显示源端口还是相当有用的。不过服务器上的端口也可能与当前设备上的服务相对应。在这种情况下，我们可以使用前面提到的netstat -lnp来找出服务所侦听的端口。

与大多数Linux命令相似，iftop也拥有多种高级选项。我们在文章中提到的这些已经足以涵盖大多数故障排查需求，但为了满足大家进一步了解iftop功能的愿望，我教各位一个小技巧：只要输入man iftop，就可以阅读包含在软件包当中的使用手册、获得更多与之相关的知识。

参考链接

Linux服务器故障排查指南：出是谁占用了带宽