xargs有个开关-P，意思是同时启动多少个子进程。借助xargs的这个特性可以加速grep文件的速度。例如，

grep  -r "libm.so.2" *

可以改写为

find . -type f | xargs -n 1 -P 20 grep "libm.so.2"

这样就会有20个进程同时查找了。

一直感觉删除一个daemontools启动的服务好麻烦。昨天strace了一下svscan和svc等程序，然后搞了个脚本专门来删这种服务。

具体细节请看: http://www.jianingy.com/killdaemontools.html

如果登录了一台机器，想把上面某个文件copy回自己的机器，有懒得ifconfig找自己机器的IP。可以用:

scp file  ${SSH_CONNECTION%% *}:~/

一台机器上mount了一很多nfs的分区，但是其中一个nfs server挂了(硬件问题一时启动不起来)。结果几个df进程就跟着挂起了，并且用kill -9也杀不掉。当时的进程状态是:

[jianingy(0)@xxxxxx ~]$ ps ax -o pid,wchan,s,command | grep df$
3505 rpc_ex D df
3844 rpc_ex D df
4162 rpc_ex D df

[jianingy(0)@xxxxxx ~]$ pstree
init─┬─acpid
    ├─agetty
    ├─atd
    ├─crond
    ├─dbus-daemon-1
    ├─3*[df]
...

所有df都wait在了rpc_execute。进程都在uninterruptible sleep(即ps的D状态)，因此不会处理任何信号。经过广泛的搜索，发现rpc_execute所需数据由rpciod提供。因此只要killall -KILL rpciod就可以终止rpc_execute调用, 而rpciod在被杀掉后会自己重启过来。

另外出现这种情况大多因为使用默认方式mount了nfs, 这种情况下连接失败时nfs客户端会不停尝试连接服务器。在mount时使用intr选项可以避免这类问题的出现。下面贴一段nfs mount option的说明

       soft           If  an  NFS  file operation has a major timeout then report an I/O error to the calling
                      program.  The default is to continue retrying NFS file operations indefinitely.

       hard           If an NFS file operation has a major timeout then report "server not responding" on the
                      console and continue retrying indefinitely.  This is the default.

       intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals
                      to interupt the file operation and cause it to return EINTR  to  the  calling  program.
                      The default is to not allow file operations to be interrupted.

我们用daemontools来控制ssh tunnel确保tunnel能在意外断开后主动连接上。在daemon中做tunnel最大的问题就是如何输入密码。这个问题可以使用以前的 ssh-attach 脚本来解决。

首先创建一个连接脚本(tunnel.sh):

#!/bin/sh
HOME=/home/jianingy
eval `$HOME/bin/ssh-attach`
ssh -p 23456 -b 0.0.0.0 -R 12345:localhost:143 xxx.xxx.xxx.xxx "vmstat 60"

再建立daemontools的run脚本:

#!/bin/sh

exec setuidgid jianingy ./tunnel.sh

用加载ssh-agent的用户(这里是jianingy)来执行tunnel.sh(即用setuidgid jianingy在指定)，酱紫tunnel.sh中调用的ssh-attach便能复用已有的ssh-agent了，保证tunnel连接无须输入密码.

这里可说的是DJB写的 daemontools , 不是DAEMON Tools那个虚拟光驱哦.

启停daemon

svc -t /service/lighttpd # 重启lighttpd
svc -u /service/lighttpd # 启动lighttpd
svc -d /service/lighttpd # 停止lighttpd

删除daemon

cd /service/lighttpd
rm -rf /service/lighttpd
svc -dx .

查看daemon的状态

svstat /service

查看daemon log

tailn64log /service/lighttpd/log/main/current

PS. 用daemontools管理lighttpd再好不过了，能够准确的定位多个lighttpd服务中你想要的那个～

netstat -ant 显示的连接状态有几种WAIT: FIN_WAIT_1,FIN_WAIT_2,CLOSE_WAIT和TIME_WAIT. 他们的含义要从TCP的连接中断过程说起

Server              Client
  -------- FIN -------->
  <------- ACK ---------
  <------- FIN ---------
  -------- ACK -------->

对于服务器主动关闭连接(Active Close):

1. 服务器首先向客户机发送FIN包，然后服务器进入FIN_WAIT_1状态。
2. 客户机向服务器确认FIN包收到，向服务器发送FIN/ACK，客户机进入CLOSE_WAIT状态。
3. 服务器收到来自客户机的FIN/ACK后，进入FIN_WAIT_2状态
4. 现在客户机进入被动关闭("passive close")状态，客户机OS等待他上面的应用程序关闭连接。一旦连接被关
   闭，客户端会发送FIN包到服务器
5. 当服务器收到FIN包后，服务器会向客户机发送FIN/ACK确认，然后进入著名的TIME_WAIT状态
6. 由于在连接关闭后，还不能确定所有连接关闭前的包都被服务器接受到了(包的接受是没有先后顺序的)，因此有了TIME_WAIT状态。在这个状态中，服务器仍然在等待客户机发送的但是还未到达服务器的包。这个状态dl.
7. 将保持2*MSL的时间，这里的MSL指的是一个TCP包在网络中存在的最长时间。一般情况下2*MSL=240秒。

很多脚本需要以root来，因此当当前用户不是root的时候可以提示并引导用户获得root权限再执行。至少比看到一对Permission Denied要有好一些。(当然是引导那些有sudo priviledge的用户去sudo咯)

自动调用sudo的shell函数:

invoke_sudo() 
{ 
    if [ "`id -u`" != "`id -u $1`" ]; then 
        echo "`whoami`: you need $1 priviledge to run this application." 
        if [ "$AUTO_INVOKE_SUDO" == "yes" ]; then 
            echo "Invkoing sudo ..." 
            sudo -u "#`id -u $1`" bash -c "$2" 
        fi 
        exit 0 
    fi 
}

使用方法是

invoke_sudo root "$0 $@"

原文地址:http://eastviking.javaeye.com/blog/32899

SVN迁移可能有很多原因, 可能是我们想换Repository目录, 或者是想换一台机器, 等等.
SVN迁移很容易做, 按照下面步骤就可以:

1. 将原来的Repository导出为一个文件dumpfile > svnadmin dump path/to/old-repo > dumpfile
2. 创建新的Repository, 创建方法可以参考 Windows 平台安装Subversion server
3. 将dumpfile导入到新的Repository > svnadmin load path/to/new-repo < dumpfile
4. 检查新的Repository的conf/目录下的配置文件, 检查hooks/目录下的构子程序等等...

KeepAlive功能是在HTTP/1.1协议中要求实现的，用来保持客户机和服务器的长连接，执子之手与子偕老。通过减少建立TCP Session的次数来提高性能。常用的配置参数有{KeepAlive, KeepAliveTimeout, MaxKeepAliveRequests}。逐个说来：KeepAlive决定是否开启KeepAlive支持(On/Off)；KeepAliveTimeout决定一个KeepAlive的连接的无请求状态最长保持的时间(以秒为单位)， 时间一到就shutdown连接，若之后又有数据传输则必须再建立新的连接了；MaxKeepAliveRequests于 KeepAliveTimeout相似，意思是服务多少个请求就shutdown连接。看个例子：

KeepAlive On
KeepAliveTimeout 5

意思是说，打开KeepAlive，每个连接只保持5秒就中断。

对于KeepAlive的配置需要慎重，错误的参数可能导致严重的性能问题。一个高负载的Server，如果建立很多长连接将无法继续服务新的连接。因此需要根据server的性质调整KeepAliveTimeout或是MaxKeepAliveRequests的值。

例如：你的网页上有三幅图画2个外部javascript，他们都存放在你自己的server上。因此将MaxKeepAliveRequests设置为7比较合适。3幅图 2个js各一个link，网页本身一个link，还有firefox传说中的favicon.ico。当然还是要有KeepAliveTimeout的。如果客户机用了该死的IE并且设置了某个该死的选项，IE是不会向服务器发送HEAD请求查看图片（或是其他资源）是否过期的，而是直接使用本地图片。这个时候服务器是不会计算Request的(因为压根就没有Request嘛)。再如果只有MaxKeepAliveRequests参数，服务器会默认等待5秒才结束KeepAlive连接。通常这5秒可能玩死一个高负载的服务器。因此打开Firefox，启动Firebug，看看你的站究竟需要多少次请求，再决定KeepAlive吧。