存档

‘Linux故障排查’ 分类的存档

您的浏览器不能播放当前视频,请点击此处安装Flash播放器 解决方法 精

2017年2月4日 评论已被关闭

您的浏览器不能播放当前视频,请点击此处安装Flash播放器 解决方法 精

说真的安装EduSoho程序真心不是那么容易呀。

 

服务器环境搭配好之后终于可以正常安装了,结果又出现了视频不能播放的问题,总是在上方提示:

 

您的浏览器不能播放当前视频,请点击此处安装Flash播放器

 

在官方客服kent的知道下终于解决了这个问题。

 

原因在于 服务器 php 未安装 fileinfo组件。

 

由于我是使用lnmp 一键安装包 搭建的环境 解决方法如下:

 

编译并安装fileinfo插件

 

cd /root/lnmp1.0-full/php-5.3.17/ext/fileinfo

/usr/local/php/bin/phpize

./configure –with-php-config=/usr/local/php/bin/php-config

make && make install

在PHP配置中添加fileinfo插件

 

用vim编辑器编辑/usr/local/php/etc/php.ini文件

找到 “;extension=php_bz2.dll” 这一行

在其上面添加一行:

extension = fileinfo.so

然后重启lnmp

/root/lnmp restart

 

视频上传不了或者视频过大不能上传

2017年2月4日 评论已被关闭

视频上传不了或者视频过大不能上传

视频上传不了,通常有3种情况:

1、服务器上传的目录被限制了访问,尤其是虚拟主机:这个目录位于 edusoho/app/data/udisk

这种情况一般不会出现,因为安装的时候已经检测过。

 

2、PHP限制了上传大小

找到php.ini,修改下列参数,重启php-fpm或者apache

 

post_max_size = 300M

upload_max_filesize = 300M

memory_limit = 300M

 

3、web服务器(Nginx,Apache)限制了上传大小

Nginx:  打开nginx.conf

并在http{}字段里添加 client_max_body_size 300M;

 

Apache:

/etc/httpd/conf.d/php.conf (不同系统位置有所不同)

LimitRequestBody 300M

Linux 下 PHP 扩展 cURL 编译安装

2017年2月3日 评论已被关闭

Linux 下 PHP 扩展 cURL 编译安装
http://www.cnblogs.com/suan07lai/p/5234868.html
下载 cURL http://pan.baidu.com/s/1hqrHWkG (curl-7.39.0.tar.gz) 3.98MB

解压:

tar zxvf curl-7.39.0.tar.gz
./configure –prefix=/usr/local/curl
make && make install

安装 curl 成功后,进入 php 的源码包(非php安装地址)

cd /var/soft/php-5.3.19/ext/curl
/usr/local/php/bin/phpize 注:/usr/local/php 为我的php安装目录
./configure –with-php-config=/usr/local/php/bin/php-config –with-curl=/usr/local/curl/
make && make install
成功后出现 curl.so 的所在目录

打开 php.ini 添加 extension=xxx/curl.so

重启 apache 即可。

NFS共享服务挂载时出现“access denied by server while mounting”的解决方法

2017年1月3日 评论已被关闭

NFS共享服务挂载时出现“access denied by server while mounting”的解决方法
http://www.2cto.com/os/201305/215679.html
笔者用的Linuxf发行版本为Centos6.4,以下方法理论上讲对于Fedora, Red Hat均有效:

搭建好NFS服务后,如果用以下的命令进行挂载:

# mount -t nfs 172.16.12.140:/home/liangwode/test /mnt

出现如下错误提示:

mount.nfs: access denied by server while mounting 172.16.12.140:/home/liangwode/test
那我们可以用以下的方法进行解决:

修改/etc/sysconfig/nfs文件,将

# Turn off v2 and v3 protocol support
# RPCNFSDARGS=”-N 2 -N 3″
# Turn off v4 protocol support
#RPCNFSDARGS=”-N 4″ /*把这句话的#号去掉*/
NFS分为三个版本,即NFS-2 NFS-3 NFS-4,该配置文件默认关闭了这三个的NFS版本,我们只需要打开NFS-4即可。

问题解决!!!
NFS共享服务挂载时出现“access denied by server while mounting”的解决方法

笔者用的Linuxf发行版本为Centos6.4,以下方法理论上讲对于Fedora, Red Hat均有效:

搭建好NFS服务后,如果用以下的命令进行挂载:

# mount -t nfs 172.16.12.140:/home/liangwode/test /mnt

出现如下错误提示:

mount.nfs: access denied by server while mounting 172.16.12.140:/home/liangwode/test
那我们可以用以下的方法进行解决:

修改/etc/sysconfig/nfs文件,将

# Turn off v2 and v3 protocol support
# RPCNFSDARGS=”-N 2 -N 3″
# Turn off v4 protocol support
#RPCNFSDARGS=”-N 4″ /*把这句话的#号去掉*/
NFS分为三个版本,即NFS-2 NFS-3 NFS-4,该配置文件默认关闭了这三个的NFS版本,我们只需要打开NFS-4即可。

问题解决!!!

oracle: linux服务器本机不能登陆的解决

2016年12月11日 评论已被关闭

 oracle: linux服务器本机不能登陆的解决

服务器本机不能登陆的解决

一台测试的数据库服务器安装好之后,每次都是使用SecureCRT远程通过ssh登陆上去操作,即使安装数据库的需要图形界面的操作,也是通过vnc远程做的,突然今天,发现这个服务器在本机不能登陆,可是远程却可以登陆,而且这台测试机器使用了很久了,也没碰见过什么异常,系统日志也查不到什么有用的东西,见鬼了?

安装oracle过程中,一般的安装文档中都会提到要设置/etc/security/limits.conf和/etc/pam.d/login参数文件来限制oracle服务器可以打开的文件数、进程数等等资源的限制,于是会需要在/etc/pam.d/login 文件中添加session required /lib/security/pam_limits.so一行内容来实现/etc/security/limits.conf中定义的各项限制,和通过ulimit命令直接设置资源设置类似,此机器的安装过程中也是这样设置的,可是问题就出现在这里了。

此机器使用的是64位的操作系统,因此根本没有/lib/security/pam_limits.so文件存在,而应该使用替代的/lib64/security/pam_limits.so文件来代替,否则在登陆的时候找不到这个文件,就会出现本机不能登陆的情况。

修改后,本机登陆正常。

提示:修改此参数不需要重新启动系统的,修改立即生效。

 

转载自:http://hi.baidu.com/dr_wang/blog/item/245b3b8913196fba0f24448c.html

分类: Linux故障排查 标签:

Linux新手入门:Unable to locate package错误解决办法+10

2016年12月10日 评论已被关闭

Linux新手入门:Unable to locate package错误解决办法+10
http://www.letuknowit.com/topics/20111125/ubuntu-unable-to-locate-package.html/
最近刚开始接触Linux,在虚拟机中装了个Ubuntu,当前的版本是Ubuntu 11.10,装好后自然少不了安装一些软件,在设置了软件的源后,就开始了 sudo apt-get install,结果出现了下面的Unable to locate package错误:

letuknowit@ubuntu:~$ sudo apt-get install mysql-server mysql-client
[sudo] password for letuknowit:
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package mysql-server
E: Unable to locate package mysql-client
letuknowit@ubuntu:~$
这叫一个郁闷啊,出师不利,不带这么吓唬刚玩Ubuntu的小朋友吧~于是赶紧找资料,又回顾下前面的操作,最后发现问题出在执行sudo apt-get install之前更换了软件源,但是却忘了update下了,于是执行下面的命令:

sudo apt-get update
等上面命令执行完后,再执行sudo apt-get install就可以了!其实错误信息已经很明确了,Unable to locate packet就是无法找到包嘛,那还不赶紧sudo apt-get update下!

分类: Linux故障排查 标签:

When is wait_timeout not wait_timeout?

2016年12月9日 评论已被关闭

When is wait_timeout not wait_timeout?
https://blog.mozilla.org/it/2012/04/24/when-is-qwait_timeout-not-wait_timeout/
Over the weekend I came across an extremely curious issue with MySQL. It seemed that no matter how many times I tried to set the wait_timeout, it would always show the value of interactive_timeout. I even tried restarting mysql, to no avail.

Eventually I figured it out. When I was in an *interactive session*, wait_timeout displays as the value of interactive_timeout. Otherwise, it showed the appropriate value. Here’s what I found, when interactive_timeout was set to 600 and wait_timeout was set to 14400 (this is on an analytics server, so setting the value that high actually makes sense):

[root@mysql1 ~]# mysql -e “show variables like ‘interactive_timeout'”
+———————+——-+
| Variable_name | Value |
+———————+——-+
| interactive_timeout | 600 |
+———————+——-+

[root@mysql1 ~]# mysql -e “show variables like ‘wait_timeout'”
+—————+——-+
| Variable_name | Value |
+—————+——-+
| wait_timeout | 14400 |
+—————+——-+

When using non-interactive logins, like mysql -e “COMMAND”, wait_timeout has the appropriate value. However, in an interactive session, wait_timeout had the same value as interactive_timeout:

[root@mysql1 ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 23814
Server version: 5.1.61-rel13.2-log Percona Server (GPL), 13.2, Revision 430

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql> show variables like ‘interactive_timeout’;
+———————+——-+
| Variable_name | Value |
+———————+——-+
| interactive_timeout | 600 |
+———————+——-+
1 row in set (0.00 sec)

mysql> show variables like ‘wait_timeout’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| wait_timeout | 600 |
+—————+——-+
1 row in set (0.00 sec)

I observed this behavior with Percona Server 5.5.21-55, and with Oracle’s MySQL 5.1.61 and 5.0.77, so it is neither a new feature, nor is it limited to Percona only.

Putting on my “reverse engineering” hat, my guess is that MySQL looks at the value of “wait_timeout” to decide when to timeout, and when you use an interactive session, wait_timeout is set to the value of interactive_timeout. In other words, I guess that interactive_timeout serves only to set wait_timeout for interactive sessions.

I am not sure if this is a bug or a feature, but I have seen plenty of these kinds of “subtle hacks” in MySQL so it would not surprise me if this is the way it was intended to work. It’s extremely confusing to figure out though, when you try to set the variable and then check it….here is one of my frustrating sessions, where the change didn’t seem to “stick”:

mysql> set global wait_timeout=14400;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like ‘wait_timeout’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| wait_timeout | 600 |
+—————+——-+
1 row in set (0.00 sec)

mysql> exit
Bye
[root@mysql1 ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 23810
Server version: 5.1.61-rel13.2-log Percona Server (GPL), 13.2, Revision 430

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> show variables like ‘wait_timeout’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| wait_timeout | 600 |
+—————+——-+
1 row in set (0.00 sec)

Edited to add: – My guesses were correct! Many people have pointed out that this is a documented way that this works.

发现大量的TIME_WAIT解决办法

2016年12月9日 评论已被关闭

发现大量的TIME_WAIT解决办法
http://kerry.blog.51cto.com/172631/105233/
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://kerry.blog.51cto.com/172631/105233
今天早上一上班,有同事就反映公司好几个网站都打不开,登陆数据库
服务器(windows),发现很卡,于是重启了下服务器,进入系统后,没过一会问题依旧,查看了下系统进程,发现mysql占用率达到99%,可以肯定的是mysql连接出现问题:
netstat -an
192.168.12.13:3306 192.168.12.12:30443 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30444 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30445 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30446 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30447 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30448 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30449 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30450 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30451 TIME_WAIT
192.168.12.13:3306 192.168.12.12:30452 TIME_WAIT
… …
根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证.
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的
DWORD键,设置为60,以缩短TIME_WAIT的等待时间

登陆到web服务器(linux):

netstat -ae |grep mysql
tcp 0 0 aaaa:53045 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53044 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53051 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53050 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53049 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53048 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53055 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53054 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53053 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53052 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53059 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53058 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53057 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53056 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53063 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53062 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53061 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53060 192.168.12.3:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53067 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53066 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53065 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53064 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa53071 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53070 192.168.12.13:mysql TIME_WAIT root 0
tcp 0 0 aaaa:53069 192.168.12.13:mysql TIME_WAIT root 0
发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,
vi /etc/sysctl.conf

编辑文件,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

修改之后,再用
netstat -ae|grep mysql
tcp 0 0 aaaa:50408 192.168.12.13:mysql ESTABLISHED nobody 3224651
tcp 0 0 aaaa:50417 192.168.12.13:mysql ESTABLISHED nobody 3224673
tcp 0 0 aaaa:50419 192.168.12.13:mysql ESTABLISHED nobody 3224675

发现大量的TIME_WAIT 已不存在,mysql进程的占用率很快就降下来的,各网站访问正常!!
以上只是暂时的解决方法,最后仔细巡查发现是前天新上线的一个系统,程序代码中没有使用mysql.colse(),才导致大量的mysql TIME_WAIT

关于too many connections问题产生原因的理解

2016年12月9日 评论已被关闭

关于too many connections问题产生原因的理解
http://blog.csdn.net/iamaboyy/article/details/7694895

产生too many connections 的直接原因是因为数据库提供的连接被全部占满了。数据库可以提供多少连接,可以再my.cnf(Linux)或者my.ini(windows)下设定。这个直接原因的上一次原因是引用程序占据连接不释放。至于为何不释放,那就是各个应用程序的具体问题了。

之前 ,遇到这个问题时,在网上找了很多关于这方面的资料,发现都不能解决这方面的问题。网上的资料只能提供一个共性的解决方案,无法提供个性的解决方案。而且,感觉网上的资料随意转载 ,没说明应用环境,有点不负责任。所以,从这个事件中,我感受到,解决自己的问题,还是得靠自己的逻辑分析。

在使用数据库连接池时,会配置数据库连接池的最小连接数,最大连接数以及默认连接数。在初始化数据库连接池时,配置的最小连接数就会来占据数据库提供的连接,而且这个连接是关闭tomcat之前,不会被释放的。列如:如果你配置的数据库连接池最小的连接数是20,那么,在tomcat上启动该应用程序,在用MySQL的线程查看命令:mysql>show processlist;时,你会发现,会有21条线程。这是因为会留有一条线程用于操作。show processlist命令显示的是Thread_connected,当Thread_connected与max_connections相等时,在企图进行数据库连接,就会出现too many connections的错误。

如果将数据库连接池交由spring管理,那么,每初始化一个spring管理容器,就会初始化一个数据库连接池,也就是(以上面配置的数据库连接池最小连接数为例)说,会占据20个数据库提供的线程,而且除非停掉tomcat,否则不会释放。这种情况下,若采用ClassPathApplicationContext(具体不太记得了,大概就这个意思)这种方式来开启一个spring容器,那么,而程序又是要被周期性调度执行,那么数据库的连接数无论被设为多大都没用。时间一长,就会出现too many connections的错误。

关于FIN_WAIT2

2016年12月8日 评论已被关闭

关于FIN_WAIT2

http://huoding.com/2016/09/05/542

前些天,有朋友问我关于 FIN_WAIT2 的问题:如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包,那么会怎样?

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

TCP Close

按照正常的状态迁移路径,当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包,那么连接状态会如何迁移,我们不妨测试一下:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 1234))
s.listen(1)

c, _ = s.accept()

time.sleep(1000)

c.close()

如上是用 Python 实现的一个简单的 server 演示代码,需要注意的是我在 close 前设置了一个巨大的延迟时间,从而达到拖延服务端发出 FIN 包的目的。与之相对应的我们再实现一个简单的 client 演示代码,它没什么可说的,就是连上后直接关闭:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 1234))
s.close()

测试的时候先启动服务端监听 1234 端口,再启动客户端连接 1234 端口,为了确认整个过程是否符合我们的预期,可以使用 tcpdump 监听通讯过程:

tcpdump -t -nn -i any port 1234

如图可见:在三次握手之后,客户端关闭了连接,服务端确认后没有发出 FIN 包,所以整个过程符合我们的预期,同时为了判断 FIN_WAIT2 存在了多久,写了如下代码:

shell> while sleep 1; do
    netstat -ant | grep FIN_WAIT2 | while read content; do
        echo -n $(date +"%T") ""
        echo $content
    done
done

监控发现,在本例中 FIN_WAIT2 存在的时间大约是一分钟左右:

FIN_WAIT2 存在的时间

实际上此时间是「net.ipv4.tcp_fin_timeout」控制的,不过在测试中发现,FIN_WAIT2 存在的时间并不是精确的等于 tcp_fin_timeout 的设置,存在一定的偏差。此外,需要说明的是在 tcp_fin_timeout 后,FIN_WAIT2 并没有迁移到 TIME_WAIT,而是直接关闭了。

关于 tcp_fin_timeout 的介绍,可以参考内核的说明:

The length of time an orphaned (no longer referenced by any application) connection will remain in the FIN_WAIT_2 state before it is aborted at the local end. While a perfectly valid “receive only” state for an un-orphaned connection, an orphaned connection in FIN_WAIT_2 state could otherwise wait forever for the remote to close its end of the connection.
Cf. tcp_max_orphans
Default: 60 seconds

介绍中提到了 orphan 的概念,指的是当一个 socket 不再被任何应用引用时,它便成为了一个孤儿,而 tcp_fin_timeout 限定了成为孤儿的 FIN_WAIT2 所能存活的时间。

注:orphan 太多的话会:The “Out of socket memory” error

或许有人会问:如果 FIN_WAIT2 没有成为孤儿,那么会如何:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 1234))

s.shutdown(socket.SHUT_WR)

time.sleep(1000)

s.close()

在这一版的 client 代码中,我们没有直接 close 连接,而是通过 shutdown 来关闭,此时客户端同样会发送 FIN 包,但是并没有释放连接,所以本例中的 FIN_WAIT2 和上例中的 FIN_WAIT2 不同,其并不会成为孤儿。通过测试发现,此时 tcp_fin_timeout 将失效,而 本例中的 FIN_WAIT2 会一直存在,直到客户端 close 连接或者退出。

实际上,同其它 TCP 状态相比,通常 FIN_WAIT2 并不会给你添什么麻烦。如果你统计服务器上的 TCP 状态,你会发现它们多数时候都很少,如果不是,那么一定是应用层面上出了问题。至于 tcp_fin_timeout,我并不建议大家把它设置得太小,因为如上所说,正常情况下,TCP 连接并不会在 FIN_WAIT2 状态上停留太久,假设真的出现 FIN 包丢失之类的情况,那么给 FIN_WAIT2 状态一个合理的存在周期是必要的,毕竟丢失的 FIN 包可能会重传,在这一点上和 TIME_WAIT 为什么要存在 2MSL 是同样的原因。既然 TIME_WAIT 缺省存在 60 秒,那么 tcp_fin_timeout 缺省设置为 60 同样是一个合理的选择。

解决 debian TAB 键不能自动补全命令的原因

2016年12月8日 评论已被关闭

解决 debian TAB 键不能自动补全命令的原因

http://phpquan.com/lamp/linux/debian-tab-apt-get/

一般情况,命令行输入 sudo apt-get ins 按 tab ,它后面会自动补全为 install 如果右面写了包的名的一部分,按 tab 它也会自动完成或列出候选的,这次装了个 debian 5 突然不好使了

首先确认是否安装了 自动补全的插件,输入

apt-get install bash-completion

问了一圈都不知道,后来还是在老外的 blog 上找到答案:

即 在 .bash_profile 里加

if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

就 ok 了

链接:http://gumelta.com/add-bash-completion-in-debian.php

完整 copy 下来吧:

Add Bash Completion In Debian

ash completion is a useful tool for completion of file paths, commands etc. By default it is enabled on Ubuntu but not on Debian. With two simple steps it can also be enabled on Debian.

1. Install bash-completion

First of all we need the install the according package:

apt-get install bash-completion

2. Add it to the bash profile

Either edit the ~/.bash_profile file to enable it only for a given user or edit /etc/profile to add it system-wide. Add the following code:
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
3. Try it

In order for it to work you have to log out and relogin and then you can make use of bash completion the usual way. E.g. issue:
apt-g

and then press the TAB key once and the command will be completed to apt-get. Or issue this:
apt

and then press TAB key twice. You can also try with
apt-get install apa

and then press TAB key once to complete as far as possible and a second time to list all options.

转自:http://hi.baidu.com/liheng_2009/

Debian 8 Tab命令无法自动补全

2016年12月8日 评论已被关闭

Debian 8 Tab命令无法自动补全
http://blog.csdn.net/langqingzailanda/article/details/50248661
在Dibian 8中使用useradd命令创建的用户默认使用dash,Tab无法自动补全

需要修改/etc/passwd中用户的属性,例如

tmp:x:1003:1003::/home/tmp:/bin/sh 修改为
tmp:x:1003:1003::/home/tmp:/bin/bash

或者在创建时加入相应参数

useradd -s /bin/bash <username>

系统dash配置

sudo dpkg-reconfigure dash
选no,就可以更改默认shell环境

另外,xfce桌面快捷键会占中tab键导致无法补全

可以按照下面链接中的方法进行解决
http://blog.163.com/thinki_cao/blog/static/83944875201303081111436/

解决 debian TAB 键不能自动补全命令的原因

2016年12月8日 评论已被关闭

解决 debian TAB 键不能自动补全命令的原因
https://my.oschina.net/yygh/blog/405403
一般情况,命令行输入 sudo apt-get ins 按 tab ,它后面会自动补全为 install 如果右面写了包的名的一部分,按 tab 它也会自动完成或列出候选的,这次装了个 debian 5 突然不好使了

首先确认是否安装了 自动补全的插件,输入

apt-get install bash-completion

问了一圈都不知道,后来还是在老外的 blog 上找到答案:

即 在 .bash_profile 里加

if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

就 ok 了

Linux Shell 按Tab键不能补全

2016年12月8日 评论已被关闭

Linux Shell 按Tab键不能补全
http://www.cnblogs.com/ainubis/p/3990005.html
今天碰到一个问题git 后面的参数用Tab键无法补全 例如git c_

在网上找了半天找到答案如下
今天在Linux上用useradd新增用户的时候,发现使用新增的用户登陆的时候,在Shell里面不能使用Tab键补全命令,按上下键也不能切换历史命令,出现乱码的现象。Root用户是OK的。

后面发现,在/etc/passwd里面,新增的用户用的Shell与root用户的不一样。

Root用的是/bin/bash

新增用户默认用的是/bin/sh

用ls -l /bin/sh发现

/bin/sh -> /bin/dash

dash与bash是不一样的,把/bin/sh改成/bin/bash后,

在我的ubuntu上运行 sudo gedit /etc/passwd 结果如下 也可以用env命令查看 shell=/bin/bash/

hailongzhou:x:1000:1000:hailongzhou,,,:/home/hailongzhou:/bin/bash
用户的shell确实是bash 可是 /bin/sh -> /bin/dash
修改Ubuntu的/bin/sh的默认连接:
终端输入:
root@zhanghc-Ubuntu:~# cd /bin
root@zhanghc-Ubuntu:/bin# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2008-04-28 19:59 /bin/sh -> dash //默认位dash
root@zhanghc-Ubuntu:/bin# ln -sf bash /bin/sh //软链接 -f表示强制
root@zhanghc-Ubuntu:/bin# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2008-05-01 22:51 /bin/sh -> bash //现在位bash了

git 后面的参数可以用Tab键补齐了
bash 与dash的区别
bash – GNU Bourne-Again SHell
dash – Debian Almquist Shell
可以分别man bash / man dash看一下。

那么怎么把sh改为指向bash呢?
最暴力的方法当然是直接把/bin/sh的软链接改到bash中,
如:ln -s /bin/bash /bin/sh
但是,有优雅一些的方法,
sudo dpkg-reconfigure dash
出现菜单问你是否要dash的时候,选no就可以了。
再次检查一下, ls /bin/sh -al 发现软链接指向/bin/bash就可以了。

Linux下程序报出/bin/bash: No such file or directory

2016年12月5日 评论已被关闭

Linux下程序报出/bin/bash: No such file or directory
https://my.oschina.net/forrest420/blog/62796
以如下脚本为例,
#!/bin/bash

conn=’mysql -upitt -p123456 -hhostname –default-character-set=UTF8 database’

`$conn -e “select Name from Product1 where Type=’Live'” > a.txt`
`$conn -e “select Name from Product2 where Type=’Live'” >> a.txt`
echo “query end”
echo “start check”

`cd /home/user/NameCheck`
`grep ‘@’ a.txt | wc -l > result.txt`

使用Notepad++编辑器,
1.Edit菜单栏里选择EOL Conversion侧栏选择UNIX Format
2.Encoding菜单栏里选择Encode in UTF-8 without BOM
这样在Linux下跑不会报出/bin/bash: No such file or directory的错误

分类: Linux故障排查 标签:

DOS/Windows和Linux/Unix的文件格式转换

2016年12月5日 评论已被关闭

DOS/Windows和Linux/Unix的文件格式转换
http://zhaizhenxing.blog.51cto.com/643480/134756
DOS/Windows和Linux/Unix的文件换行回车格式不同,基于 DOS/Windows 的文本文件在每一行末尾有一个 CR(回车)和 LF(换行),而 UNIX 文本只有一个换行。

1)、把Dos/Windows下的文件移至Linux/Unix系统

虽然很多程序不在乎 DOS/Windows 格式的 CR/LF 文本文件,但是有几个程序却在乎 — 最著名的是 bash,只要一遇到回车,它就会出问题。以下 sed 调用将把 DOS/Windows 格式的文本转换成可信赖的 UNIX 格式:

$ sed -e ‘s/.$//’ mydos.txt > myunix.txt

该脚本的工作原理很简单:替代规则表达式与一行的最末字符匹配,而该字符恰好就是回车。我们用空字符替换它,从而将其从输出中彻底删除。如果使用该脚本并注意到已经删除了输出中每行的最末字符,那么,您就指定了已经是 UNIX 格式的文本文件。也就没必要那样做了!

2)、把Linux/UNIX 文本移至 Windows 系统,使用以下脚本执行必需的格式转换:

$ sed -e ‘s/$/\r/’ myunix.txt > mydos.txt

在该脚本中,’$’ 规则表达式将与行的末尾匹配,而 ‘\r’ 告诉 sed 在其之前插入一个回车。在换行之前插入回车,立即,每一行就以 CR/LF 结束。请注意,仅当使用 GNU sed 3.02.80 或以后的版本时,才会用 CR 替换 ‘\r’。

3)使用dos2unix和unix2dos命令,这种方法最简单。

在window上随便创建一个文件Noname2.txt,内容如下:
sfadadfad
sfasd
fads
fasdfads

在Linux上用hexdump工具进行查看:

A52>hexdump Noname2.txt
0000000 6673 6461 6461 6166 0d64 730a 6166 6473
0000010 0a0d 6166 7364 0a0d 6166 6473 6166 7364
0000020 0a0d
0000022

用dos2unix工具转换后:

A52>dos2unix Noname2.txt
dos2unix: converting file Noname2.txt to UNIX format …

A52>hexdump Noname2.txt
0000000 6673 6461 6461 6166 0a64 6673 7361 0a64
0000010 6166 7364 660a 7361 6664 6461 0a73
000001e

再使用unix2dos转换回去:

A52>unix2dos Noname2.txt
unix2dos: converting file Noname2.txt to DOS format …

A52>hexdump Noname2.txt
0000000 6673 6461 6461 6166 0d64 730a 6166 6473
0000010 0a0d 6166 7364 0a0d 6166 6473 6166 7364
0000020 0a0d
0000022

Sublime 在 Windows 下開發出現「-bash: /bin/bash^M: bad interpreter: No such file or directory」

2016年12月5日 评论已被关闭

Sublime 在 Windows 下開發出現「-bash: /bin/bash^M: bad interpreter: No such file or directory」

之前都是使用 MacOS 開發,這兩天因為換工作而且新的 Macbook Pro 遲遲未開售,所以僅能使用手邊的 Windows 進行開發

小弟是使用 sublime text 3 當作開發工具,但是在上傳 source code 到 Linux 環境的時候出現錯誤訊息

-bash: /bin/bash^M: bad interpreter: No such file or directory

這個看起來很明顯的是編碼問題,但是我在 Sublime 上儲存成 UTF-8,並且在 Preferences 也加入了 “default_encoding”: “UTF-8″,依然還是出現這個問題

幾經查詢後在一篇 stackoverflow 找到解決方案

在裡面其中一個回答提到

If you use Sublime Text on Windows or Mac to edit your scripts:

Click on View > Line Endings > Unix and save the file again.

將換行格式(Line Endings) 由 Windows 改為 Unix 在儲存一次檔案就可以解決這個問題!

參考資料:

-bash: ./my_script: /bin/bash^M: bad interpreter: No such file or directory

分类: Linux故障排查 标签:

服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

2016年12月4日 评论已被关闭

服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

来自:http://blog.csdn.net/shootyou/article/details/6622226

 

昨天解决了一个HttpClient调用错误导致的服务器异常,具体过程如下:

http://blog.csdn.net/shootyou/article/details/6615051

里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。

 

在服务器的日常维护过程中,会经常用到下面的命令:

  1. netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

它会显示例如下面的信息:

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

 

具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:

 

这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

因为linux分配给一个用户的文件句柄是有限的(可以参考:http://blog.csdn.net/shootyou/article/details/6579139),而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃。。。

下 面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参 数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:

 

1.服务器保持了大量TIME_WAIT状态

这种情况比较常见,一些爬虫服务器或者WEB服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题,这个问题是怎么产生的呢?

从 上面的示意图可以看得出来,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就 会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定 的,主要出于以下两个方面的考虑:

1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
2. 可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。

关于MSL引用下面一段话:

  1. MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間),由 於 RFC 793 TCP 傳輸協定是在 1981 年定義的,當時的網路速度不像現在的網際網路那樣發達,你可以想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎?在現在的網路環境下幾乎不可能有這種事情發生,因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低,好 讓 連線埠 (Ports) 能更快空出來給其他連線使用。

再引用网络资源的一段话:

  1. 值 得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访 问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压 240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些 TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。
  2. HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。

也就是说HTTP的交互跟上面画的那个图是不一样的,关闭连接的不是客户端,而是服务器,所以web服务器也是会出现大量的TIME_WAIT的情况的。

现在来说如何来解决这个问题。
解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
下面来看一下我们网管对/etc/sysctl.conf文件的修改:
  1. #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
  2. net.ipv4.tcp_syn_retries=2
  3. #net.ipv4.tcp_synack_retries=2
  4. #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
  5. net.ipv4.tcp_keepalive_time=1200
  6. net.ipv4.tcp_orphan_retries=3
  7. #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
  8. net.ipv4.tcp_fin_timeout=30
  9. #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
  10. net.ipv4.tcp_max_syn_backlog = 4096
  11. #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
  12. net.ipv4.tcp_syncookies = 1
  13. #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
  14. net.ipv4.tcp_tw_reuse = 1
  15. #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
  16. net.ipv4.tcp_tw_recycle = 1
  17. ##减少超时前的探测次数
  18. net.ipv4.tcp_keepalive_probes=5
  19. ##优化网络设备接收队列
  20. net.core.netdev_max_backlog=3000
修改完之后执行/sbin/sysctl -p让参数生效。
这里头主要注意到的是net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
这几个参数。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_*一系列参数,是用来设置服务器检测连接存活的相关配置。
2.服务器保持了大量CLOSE_WAIT状态
休息一下,喘口气,一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别,没想到越挖越深,这也是写博客总结的好处,总可以有意外的收获。
TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
但 是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程 序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直 被程序占着。个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。
如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况,那么这篇日志也许对你有用:http://blog.csdn.net/shootyou/article/details/6615051
在那边日志里头我举了个场景,来说明CLOSE_WAIT和TIME_WAIT的区别,这里重新描述一下:
服 务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。
所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。
参考资料:
1.windows下的TIME_WAIT的处理可以参加这位大侠的日志:http://blog.miniasp.com/post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx
3.各种内核参数的含义:http://haka.sharera.com/blog/BlogTopic/32309.htm
4.linux服务器历险之sysctl优化linux网络:http://blog.csdn.net/chinalinuxzend/article/details/1792184

nginx修改上传文件大小限制

2016年12月4日 评论已被关闭

nginx修改上传文件大小限制
http://blog.csdn.net/bruce128/article/details/9665503
新装了一台服务器,用nginx做代理。突然发现上传超过1M大的客户端文件无法正常上传,于是修改了下nginx的配置。
cd /export/servers/nginx/conf/nginx.conf,在这个配置文件里面的server段里面的
[plain] view plain copy
location / {
root html;
index index.html index.htm;
client_max_body_size 1000m;
}
加上了client_max_body_size 字段,怎么重启都不行。后来在总配置文件里面发现了分配置文件:
[plain] view plain copy
sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;
include domains/*; #########################分配置文件路径在此
#include domains/chat.local;
#include domains/chat.erp.com;
#include domains/support.chat.com;
#include douains/chat.com;

server {
listen 80;
server_name localhost;
include domains/*命令指定了分配置文件的路径。找到了分配置文件后,在分配置文件里面进行修改。分配置文件配置如下:
[plain] view plain copy
server
{
listen 80;
server_name chat.erp.360buy.com;
#access_log /export/servers/nginx/logs/chat.erp.360buy.com;
location / {
proxy_pass http://tomcat;
client_max_body_size 1000m;
}
}
用/export/servers/nginx/sbin/nginx -s reload重启下,上传文件的大小受限的问题就解决了。
分享下我的解决过程,希望对大家有帮助。

PHP和Nginx 文件上传大小限制问题解决方法

2016年12月4日 评论已被关闭

PHP和Nginx 文件上传大小限制问题解决方法
http://kure6.blog.51cto.com/2398286/1272799
对于nginx+php的一些网站,上传文件大小会受到多个方面的限制,一个是nginx本身的限制,限制了客户端上传文件的大小,一个是php.ini文件中默认了多个地方的设置。所以为了解决上传文件大小限定的问题必须要做出多处修改。以下整理了几个地方。

1、修改/usr/local/nginx/conf/nginx.conf 文件,查找 client_max_body_size 将后面的值设置为你想设置的值。比如:
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
root /home/www/htdocs;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/www/htdocs$fastcgi_script_name;
include fastcgi_params;

client_max_body_size 35m; #客户端上传文件大小设为35M
client_body_temp_path /home/www/nginx_temp; #设置临时目录
}

2、修改php.ini
在php.ini里面查看如下行:
upload_max_filesize = 8M
post_max_size = 10M
memory_limit = 20M
max_execution_time=300
file_uploads = On

默认允许HTTP文件上传,此选项不能设置为OFF。
upload_tmp_dir =/tmp/www

在上传大文件时,你会有上传速度慢的感觉,当超过一定的时间,会报脚本执行超过30秒的错误,这是因为在php.ini配置文件中max_execution_time配置选项在作怪,其表示每个脚本最大允许执行时间(秒),0 表示没有限制。你可以适当调整max_execution_time的值,不推荐设定为0。