蓝天

Cron连接正常工作5次后异常原因分析

目录

目录 1

问题描述 1

分析定位 1

解决方法 2

附1:Cron工作流 3

附2:SIGPIPE发生的位置 3

 

如果一个shell命令的“$?”值为141,则它是收到了SIGPIPE信号。一些shell脚本中的sleep或ps、wc等命令无效,也可能是本文描述的原因,解决办法是忽略掉SIGPIPE,脚本中可以加句:trap "" SIGPIPE。

问题描述

在Crontab中仅配置如下一条命令(为简化问题的描述和定位,剔除所有其它的):

*/1 * * * * echo hello >> /tmp/hello.txt

 

也就是每分钟执行一下“echo hello >> /tmp/hello.txt”。

 

通过观察发现:

每次重启cron进程后,都只能连续正常工作5次,也就是可以看到“/tmp/hello.txt”新增5行“hello”。

分析定位

借助strace工具,cron进程仍然在工作,只是发生了异常:

[pid 12497] select(5, NULL, [4], NULL, {0, 10000}) = 1 (out [4], left {0, 10000})

[pid 12497] --- SIGPIPE (Broken pipe) @ 0 (0) ---

Process 12497 detached

--- SIGCHLD (Child exited) @ 0 (0) ---

 

发生了SIGPIPE,导致了子进程退出。翻阅cron的源代码,确认cron没有调用“signal(SIGPIPE, SIG_IGN);”来忽略SIGPIPE,因此当收到SIGPIPE信号时,进程必然退出。

 

进一步追踪发现,PIPE连接的是“/usr/local/sa/agent/log/sap1012.sock”,另一端则是sap1012

# lsof /usr/local/sa/agent/log/sap1012.sock

COMMAND   PID USER   FD   TYPE     DEVICE SIZE       NODE NAME

sap1012 15415 root    5u  unix 0xd940de40      3985983520 /usr/local/sa/agent/log/sap1012.sock

sap1012 15415 root   11u  unix 0xe22fa3c0      3970596394 /usr/local/sa/agent/log/sap1012.sock

# ls -l /proc/15415

lrwxrwxrwx  1 root root 0 Apr 17 12:43 exe -> /usr/local/sa/agent/plugins/sap1012-v5.1.4

 

使用valgrind可以看到对PIPE的写(send)是在“/lib/libsandbox_web_ips.so”中进行的,利用ldd可以发现这个共享库在编译期间就被链接进了cron程序文件中:

# ldd /usr/sbin/cron

        linux-gate.so.1 =>  (0xffffe000)

        /lib/libbash_strip_env.so (0xb7f8c000)

        /lib/libsandbox_web_ips.so (0xb7f85000)

        libpam.so.0 => /lib/libpam.so.0 (0xb7f70000)

        libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7f6d000)

        libc.so.6 => /lib/libc.so.6 (0xb7e4b000)

        libdl.so.2 => /lib/libdl.so.2 (0xb7e47000)

        libpthread.so.0 => /lib/libpthread.so.0 (0xb7e32000)

        libaudit.so.0 => /lib/libaudit.so.0 (0xb7e1f000)

        /lib/ld-linux.so.2 (0xb7f90000)

 

在Google和Baidu中找不到任何有关“libsandbox_web_ips.so”的踪影,猜测是有可能是私有的。Cron的Makefile本身并没有包含libsandbox_web_ips.so”和“/lib/libbash_strip_env.so”,如:

cc  -o cron cron.o database.o user.o entry.o job.o do_command.o misc.o env.o popen.o compat.o

 

经实践确认,编译生成可执行文件后,可执行文件都会依赖“libsandbox_web_ips.so”和“/lib/libbash_strip_env.so”两个共享库,而且它们可能会在被加载时自动执行,但因为符号被stripped掉了,看不到细节。

 

终于在/etc/ld.so.preload中找到了两者:

# cat /etc/ld.so.preload

/lib/libbash_strip_env.so

/lib/libsandbox_web_ips.so

 

它们两个如同木马,会伴随任一程序一起运行,但libsandbox_web_ips.so可能存在问题,导致cron运行异常。

解决方法

kill掉sap1012进程,然后重启cron进程,这样cron就可以正常工作了。cron必须在sap1012之前启动,以规避问题。通过strace会发现变成如下:

[pid 11704] socket(PF_FILE, SOCK_STREAM, 0) = 3

[pid 11704] fcntl64(3, F_GETFL)         = 0x2 (flags O_RDWR)

[pid 11704] fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0

[pid 11704] connect(3, {sa_family=AF_FILE, path="/usr/local/sa/agent/log/sap1012.sock"}, 110) = -1 ECONNREFUSED (Connection refused)

[pid 11704] close(3) 

 

更好的解决办法将/lib/libbash_strip_env.so和/lib/libsandbox_web_ips.so,从/etc/ld.so.preload中剔除,但是它们就不能发挥作用了。

附1:Cron工作流

真正运行Cron命令的是vfork(有些版本为fork调用)出来的进程,写标准输出的fork是可选的,只有当存在“%”配置时才会生效,目的是通过写标准输出往vfork产生的进程输入内容。

附2:SIGPIPE发生的位置

SIGPIPE正是发生在下图所示的“send()”调用,至于是因为sap1012关闭了读端,还是其它原因,暂不清楚原因。

 

posted on 2018-09-11 15:04  #蓝天  阅读(320)  评论(0编辑  收藏  举报

导航