分类目录归档:linux

tomcat进程意外退出的问题分析

节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory的整个过程:

org.apache.coyote.AbstractProtocol pause
Pausing ProtocolHandler
org.apache.catalina.core.StandardService stopInternal
Stopping service Catalina
org.apache.coyote.AbstractProtocol stop
Stopping ProtocolHandler
org.apache.coyote.AbstractProtocol destroy
Destroying ProtocolHandler

从上面日志来可以判断:

1) tomcat不是通过脚本正常关闭(viaport: 即通过8005端口发送shutdown指令)

因为正常关闭(viaport)的话会在 pause 之前有这样的一句warn日志:

    org.apache.catalina.core.StandardServer await
    A valid shutdown command was received via the shutdown port. Stopping the Server instance.
    然后才是 pause -> stop -> destroy 
2) tomcat的shutdownhook被触发,执行了销毁逻辑

而这又有两种情况,一是应用代码里有地方用System.exit来退出jvm,二是系统发的信号(kill -9除外,SIGKILL信号JVM不会有机会执行shutdownhook)

先通过排查代码,应用方和中间件团队都排查了System.exit在这个应用中使用的可能。那就只剩下Signal的情况了;经过一番排查后,发现每次tomcat意外退出的时间与ssh会话结束的时间正好吻合。

有了这个线索之后,银时同学立刻看了一下对方测试环境的脚本,简化后如下:

$ cat test.sh
#!/bin/bash
cd /data/server/tomcat/bin/
./catalina.sh start
tail -f /data/server/tomcat/logs/catalina.out

tomcat启动为后,当前shell进程并没有退出,而是挂住在tail进程,往终端输出日志内容。这种情况下,如果用户直接关闭ssh终端的窗口(用鼠标或快捷键),则java进程也会退出。而如果先ctrl-c终止test.sh进程,然后再关闭ssh终端的话,则java进程不会退出。

这是一个有趣的现象,catalina.sh start方式启动的tomcat会把java进程挂到init(进程id为1)的父进程下,已经与当前test.sh进程脱离了父子关系,也与ssh进程没有关系,为什么关闭ssh终端窗口会导致java进程退出?

我们的推测是ssh窗口在关闭时,对当前交互的shell以及正在运行的test.sh等子进程发送某个退出的Signal,找了一台装有systemtap的机器来验证,所用的stap脚本是从涧泉同学那里copy的:

function time_str: string () {
    return ctime(gettimeofday_s() + 8 * 60 * 60);
}

probe begin {
    printdln(" ", time_str(), "BEGIN");
}

probe end {
    printdln(" ", time_str(), "END");
}

probe signal.send {
    if (sig_name == "SIGHUP" || sig_name == "SIGQUIT" || 
        sig_name=="SIGINT" || sig_name=="SIGKILL" || sig_name=="SIGABRT") {
        printd(" ", time_str(), sig_name, "[", uid(), pid(), cmdline_str(), 
                "] -> [", task_uid(task), sig_pid, pid_name, "], ");
        task = pid2task(pid());
        while (task_pid(task) > 0) {
            printd(" ", "[", task_uid(task), task_pid(task), task_execname(task), "]");
            task = task_parent(task);
        }
        println("");
    }
}

模拟时的进程层级(pstree)大致如下,tomcat启动后java进程已经脱离test.sh,挂在init下:

|-sshd(1622)-+-sshd(11681)---sshd(11699)---bash(11700)---test.sh(13285)---tail(13299)

经过内核组伯俞的协助,我们发现

a) 用 ctrl-c 终止当前test.sh进程时,系统events进程向 java 和 tail 两个进程发送了SIGINT 信号
SIGINT [ 0 11  ] -> [ 0 20629 tail ] 
SIGINT [ 0 11  ] -> [ 0 20628 java ] 
SIGINT [ 0 11  ] -> [ 0 20615 test.sh ] 

注pid 11是events进程
b) 关闭ssh终端窗口时,sshd向下游进程发送SIGHUP, 为何java进程也会收到?
SIGHUP [ 0 11681 sshd: hongjiang.wanghj [priv] ] -> [ 57316 11700 bash ] 
SIGHUP [ 57316 11700 -bash ] -> [ 57316 11700 bash ]
SIGHUP [ 57316 11700 ] -> [ 0 13299 tail ] 
SIGHUP [ 57316 11700 ] -> [ 0 13298 java ] 
SIGHUP [ 57316 11700 ] -> [ 0 13285 test.sh ] 

不过伯俞很忙没有继续协助分析这个问题(他给出了一些猜测,但后来证明并不是那样)。

确定了是由signal引起的之后,我的疑惑变成了:

1) 为什么SIGINT (kill -2) 不会让tomcat进程退出?
2) 为什么SIGHUP (kill -1) 会让tomcat进程退出?

我第一反应可能是jvm在某些参数下(或因为某些jni)对os的信号处理会不同,看了一下应用的jvm参数,没有看出问题,也排除了tomcat使用apr/tcnative的情况。

我们看一下默认情况下,jvm进程对SIGINTSIGHUP是怎么处理的,用scala的repl模拟一下:

scala> Runtime.getRuntime().addShutdownHook(
            new Thread() { override def run() { println("ok") } })

对这个java进程分别用kill -2kill -1发现都会导致jvm进程退出,并且也触发shutdownhook。这也符合oracle对hotspot虚拟机处理Signal的说明,参考这里SIGTERM,SIGINT,SIGHUP三种信号都会触发shutdownhook

看来并不是jvm的事,继续猜测是否与进程的状态有关?catalina.sh脚本里并没有使用start-stop-daemon之类的方式启动java进程,start参数的执行方式简化后脚本相当于:

eval '"/pathofjdk/bin/java"' 'params' org.apache.catalina.startup.Bootstrap start '&'

就是简单的把java放到后台执行。当catalina.sh自身进程退出后,java进程的ppid变成了1

花了很多的时间猜测可能是OS层面的原因,后来发现并没有关系。春节后回来让少明和涧泉也一起分析这个问题,因为他们有c的背景,对系统底层知道的多一些,用了大半天时间,不断猜测和验证,最后确认了是Shell的原因。

SIGINT (kill -2) 不会让后台java进程退出的原因

为了简便,我们用sleep来模拟进程,当我们在交互模式下:

$ sleep 1000 & 

$ ps -opid,pgid,ppid,stat,cmd -C sleep
  PID  PGID  PPID STAT CMD
 9897  9897  9813 S    sleep 1000   

注意,进程sleep 1000的pid与pgid(进程组)是相同的,这时我们用kill -2是可以杀掉sleep 1000进程的。

现在我们把sleep进程放到一个脚本里后台执行:

$ cat a.sh
#!/bin/sh
sleep 4400 &
echo "shell exit"

运行a.sh脚本之后,sleep 4400进程的pid与pgid是不同的,pgid是其父进程的id,即已经退出了的a.sh进程

$ ps -opid,pgid,ppid,comm -p 63376
  PID  PGID  PPID COMM
63376 63375     1 sleep

这时我们用kill -2是杀不掉sleep 4400进程的。

到了这一步,已经非常接近原因了,一定是shell对后台进程signal_handler做了什么手脚。少明实现了一个自定handler的命令看看是否对kill -2有效:

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>

void my_handler(int sig) {
    printf("handler aaa\n");
    exit(0);
}

int main() {
    signal(SIGINT, my_handler);
    for(;;) { }
    return 0;
}

我们把编译后的a.out命令在脚本里以后台方式运行:

$ cat a.sh
#!/bin/sh
/tmp/a.out &

这次再尝试用kill -2去杀a.out进程,是可以的。这说明shell对signal_handler做手脚是在执行用户逻辑之前,也就是脚本在fork出子进程的时候就设置了。按照这个线索我们google后了解到: shell在非交互模式下对后台进程处理SIGINT信号时设置的是IGNORE

交互模式与非交互模式对作业控制(job control)默认方式不同

为什么在交互模式下shell不会对后台进程处理SIGINT信号设置为忽略,而非交互模式下会设置为忽略呢?还是比较好理解的,举例来说,我们先某个前台进程运行时间太长,可以ctrl-z中止一下,然后通过bg %n把这个进程放入后台,同样也可以把一个cmd &方式启动的后台进程,通过fg %n放回前台,然后在ctrl-c停止它,当然不能忽略SIGINT

为何交互模式下的后台进程会设置一个自己的进程组ID呢?因为默认如果采用父进程的进程组ID,父进程会把收到的键盘事件比如ctrl-c之类的SIGINT传播给进程组中的每个成员,假设后台进程也是父进程组的成员,因为作业控制的需要不能忽略SIGINT,你在终端随意ctrl-c就可能导致所有的后台进程退出,显然这样是不合理的;所以为了避免这种干扰后台进程设置为自己的pgid。

而非交互模式下,通常是不需要作业控制的,所以作业控制在非交互模式下默认也是关闭的(当然也可以在脚本里通过选项set -m打开作业控制选项)。不开启作业控制的话,脚本里的后台进程可以通过设置忽略SIGINT信号来避免父进程对组中成员的传播,因为对它来说这个信号已经没有意义。

回到tomcat的例子,catalina.sh脚本通过start参数启动的时候,就是以非交互方式后台启动,java进程也被shell设置了忽略SIGINT信号,因此在ctrl-c结束test.sh进程时,系统发送的SIGINT对java没有影响。

SIGHUP (kill -1) 让tomcat进程退出的原因

在非交互模式下,shell对java进程设置了SIGINTSIGQUIT信号设置了忽略,但并没有对SIGHUP信号设为忽略。再看一下当时的进程层级:

|-sshd(1622)-+-sshd(11681)---sshd(11699)---bash(11700)---test.sh(13285)---tail(13299)

sshd把SIGHUP传递给bash进程后,bash会把SIGHUP传递给它的子进程,并且对于其子进程test.sh,bash还会对test.sh的进程组里的成员都传播一遍SIGHUP。因为java后台进程从父进程catalina.sh(又是从其父进程test.sh)继承的pgid,所以java进程仍属于test.sh进程组里的成员,收到SIGHUP后退出。

如果我们在test.sh里设置开启作业控制的话,就不会让java进程退出了

#!/bin/bash
set -m  
cd /home/admin/tt/tomcat/bin/
./catalina.sh start
tail -f /home/admin/tt/tomcat/logs/catalina.out

此时java后台进程继承父进程catalina.sh的pgid,而catalina.sh不再使用test.sh的进程组,而是自己的pid作为pgid,catalina.sh进程在执行完退出后,java进程挂到了init下,java与test.sh进程就完全脱离关系了,bash也不会再向它发送信号。

在mac下制作linux启动U盘

先通过diskutil确认U盘的设备块

% diskutil list

/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *251.0 GB   disk0
1:                        EFI EFI                     209.7 MB   disk0s1
2:                  Apple_HFS Mac                     57.5 GB    disk0s2
3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
4:                  Apple_HFS Data                    192.5 GB   disk0s4
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *16.4 GB    disk1
1:                        EFI EFI                     209.7 MB   disk1s1
2:                  Apple_HFS Untitled                16.0 GB    disk1s2

上面显示的是我本机的磁盘设备,disk0是硬盘,disk1是U盘设备。

在通过dd命令写U盘的时候需要unmount,注意不能在finder里推出U盘,那样的话整个设备块也卸载了。

 % diskutil unmountDisk /dev/disk1
 Unmount of all volumes on disk1 was successful

现在可以把ISO文件写入U盘了

% sudo dd if=/data/ubuntu-13.10-server-amd64.iso of=/dev/disk1 bs=1024

阿里云vps上mysql挂掉的解决办法

用阿里云的vps用作blog服务器,系统很稳定,已经100多天一直运行正常,大概从上个月开始发现blog的mysql会有时挂掉,会收到短信通知。之前没太追究,重新启动了mysql解决的。今天上午又收到短信,已经第三次了。

查了一下日志,三次基本都是一样的:

130728  6:50:14 [Note] Plugin 'FEDERATED' is disabled.
130728  6:50:14 InnoDB: The InnoDB memory heap is disabled
130728  6:50:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130728  6:50:14 InnoDB: Compressed tables use zlib 1.2.3.4
130728  6:50:14 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
130728  6:50:14 InnoDB: Completed initialization of buffer pool
130728  6:50:14 InnoDB: Fatal error: cannot allocate memory for the buffer pool
130728  6:50:14 [ERROR] Plugin 'InnoDB' init function returned error.
130728  6:50:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130728  6:50:14 [ERROR] Unknown/unsupported storage engine: InnoDB
130728  6:50:14 [ERROR] Aborting
130728  6:50:14 [Note] /usr/sbin/mysqld: Shutdown complete

解决方法:
1) 在 /etc/mysql/my.cnf 的 mysqld 下增加下面一句:

innodb_buffer_pool_size = 64M

还要设置一下swap分区,因为我的vps是没有swap分区的,通过fdisk -l1mount 看不到swap的信息,需要手动添加一下。

2) 添加swap分区的步骤:

2.1) dd if=/dev/zero of=/swapfile bs=1M count=1024
2.2) mkswap /swapfile
2.3) swapon /swapfile
2.4) 添加这行: /swapfile swap swap defaults 0 0 到 /etc/fstab

目前已经设置了swap分区,并重启了mysql,后续观察一下看看还会不会出现吧。

参考:http://stackoverflow.com/questions/10284532/amazon-ec2-mysql-aborting-start-because-innodb-mmap-x-bytes-failed-errno-12

补充,经过近2个月观察,没再发生down掉的情况。

mysql忘记root密码的恢复方式

1) 先停止mysql进程

2) 设置初始文件,内容如下

UPDATE mysql.user SET Password=PASSWORD('newPassword') WHERE User='root';
FLUSH PRIVILEGES;

3) 重启动 mysql

$ mysqld_safe --init-file=/tmp/cure &

注,在某些服务器上,启动mysql时,不能在bin目录下执行 ./mysqld_safe 启动不成功,而要在上级目录下
$ ./bin/mysqld_safe --init-file=/tmp/cure &

ubuntu下mysql开机启动的问题

ubuntu下安装mysql后发现默认开机会启动,尝试通过sysv-rc-conf命令将mysql开机启动取消,但并不生效。看过了在/etc/rc2.d/ 下mysql脚本是以K开头的(S开头表示start,改成其他则不会被启动;K表示kill),是正常的,很奇怪。

搜了一下,原来mysql同时定义了upstart-job/etc/init/mysql.conf 里面定义了 start on levels;要想开机不启动的话,需要修改这个启动级别。

修改 /etc/init/mysql.conf 里的内容,start on  runlevel [2345] 将里面的2去掉

有关upstart:
http://askubuntu.com/questions/19320/whats-the-recommend-way-to-enable-disable-services

linux下保留网站flash视频的方法

之前从commandlinefu上看到过这样的脚本,再说一下过程:

1)找到 plugin-co 进程的 pid 和 fd

$ lsof -n | grep deleted
......
plugin-co 2253  hongjiang   22u      REG                8,1   553608    2097199 /tmp/FlashXXRNz5bo (deleted)
plugin-co 2253  hongjiang   24r      REG                8,1  1230967    2097200 /tmp/FlashXXQYyZ2Q (deleted)

其实flash文件也会有规律的命名为 FlashXX 可以 lsof -n | grep /tmp/FlashXX

2) 将 /proc下该进程的句柄拷贝到指定路径

$ cp /proc/2253/fd/22   /tmp/song

3) 播放

$ mplayer /tmp/song

lsof查看进程在使用的已删除的文件

有时会遇到这种情况,当一个进程正在向一个文件写数据时,该文件的目录可能被移动,或该文件已被其他进程删除。
lsof +L1 可以查看那些在访问的已被删除的文件

lsof +L1 shows you all open files that have a link count less than 1, often indicative of a cracker trying to hide something

hongjiang@whj ~ % sudo lsof +L1
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
mysqld  22070 mysql    4u   REG  202,1        0     0 1048935 /tmp/ibfwFj0I (deleted)
mysqld  22070 mysql    5u   REG  202,1        0     0 1048937 /tmp/ibpUnKvR (deleted)
mysqld  22070 mysql    6u   REG  202,1        0     0 1048942 /tmp/ibXYbb1Z (deleted)

这个参数不好记,也可以用 lsof -n | grep deleted 来查看。

高版本的sort支持–parallel选项

sort 在对大文件排序时很慢,8.11版本(遗憾我的xubuntu11.10还是8.5) 已经支持了 –parallel 并行运算。

这里也有一些介绍如何用sort做并行排序的方法:
http://linuxwebdev.blogspot.com/2009/02/howto-simple-parallel-sort-in-linux.html
http://bashcurescancer.com/sorting-large-files-faster-with-a-shell-script.html
http://stackoverflow.com/questions/930044/why-unix-sort-command-could-sort-a-very-large-file

commandlinefu上还看到可以设置buffersize,可以设置缓存大一些,这在大内存机器上应该有利,不知道默认情况这个buffer大小是多少。

补充:看了一下刚发布的 ubuntu12.04 beta版,里面的coreutils版本是8.13,下载了源码,sort.c 里面是有parallel选项的。
看里面的注释:

/* 
Heuristic(启发式的) value for the number of lines for which it is worth creating
a subthread, during an internal merge sort(内部是归并排序).  I.e., it is a small number of "average" lines for which sorting via two threads is faster than 
sorting via one on an "average" system.  On a dual-core 2.0 GHz i686
system with 3GB of RAM and 2MB of L2 cache, a file containing 128K
lines of gensort -a output is sorted slightly faster with --parallel=2  than with --parallel=1.  By contrast, using --parallel=1 is about 10%
faster than using --parallel=2 with a 64K-line input.  
*/

注意里面说的,128k行的用 parallel=2parallel=1 略微快一些,但64k行的用 parallel=1parallel=2快10% 我还没有测试过。需要对比一下才好说。

ubuntu下修改屏幕亮度

快捷键 Fn+Home/End 从最亮(15)往下调节时,直接降到12,跳过了中间的14,13,为了能更精确的调节屏幕亮度google了一番;自定义亮度的有效方法是:

$ echo 13 | sudo tee /sys/class/backlight/acpi_video0/brightness

再谈linux下随机数的产生

在创建临时账号初始密码时或许有用

1) 使用md5sum对已有数据加密产生

$ date +”%N” | md5sum

2) 通过/dev/urandom

$ < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32}; echo
$ < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c6; echo 
$ tr -cd '[:alnum:]' < /dev/urandom | fold -w30 | head -n1
$ dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev
$ strings /dev/urandom | grep -o "[0-9]" | head -n 30 | tr -d '\n'; echo

3) 使用SHA对已有数据加密产生

$ date +%s | sha256sum | base64 | head -c 32 ; echo   

4) 使用 openssl

$ openssl rand -base64 32 

相关阅读:shell里产生随机数的几种方式 ,用date的纳秒做随机数不严禁

另外推荐一篇关于随机数拖慢应用响应的文章,可以更好的了解一下linux的熵池。