如何找到挂起perl脚本(linux进程)的位置

时间:2012-04-29 06:54:09

标签: perl process

我很难重现perl进程挂起的情况。我不确定它挂在哪里。 ps ax | grep <process name>将stat列显示为SN,我理解这意味着它正在睡眠并且正在以优先级运行。

我查看了脚本(那里有大量的代码),但看不到任何持续超过几秒的特定睡眠(这个过程已经睡了一天多了)。

我无法重新启动并将日志添加到Perl脚本,因为可能无法再现该条件。我可以尝试strace,但想知道是否有更好的机制

2 个答案:

答案 0 :(得分:4)

一种可能的方法是使用gdb

首先,您需要为perl解释器调试符号。例如,在我的Debian系统上,我必须为此安装perl-debug包。安装完成后我们有/usr/lib/debug/usr/bin/perl,我们稍后会将其传递给gdb。请注意,原始卡住的Perl脚本是使用/usr/bin/perl启动的,而不是新安装的调试版本。

为了这个例子,让我们运行这个Perl脚本:

$ cat test.pl 
#! /usr/bin/perl

use strict;
use warnings;

print "pid: ", $$, "\n";

while (1) {
  print "line ", __LINE__, "\n"; sleep 1;
  print "line ", __LINE__, "\n"; sleep 1;
}

当我们运行它时,我们得到一个输出:

$ ./test.pl 
pid: 15764
line 9
line 10
line 9
line 10
^C

现在让我们启动gdb。使用test.pl现在运行的pid打印。我们在一些初始信息(“从......读取符号”)后得到提示:

$ gdb /usr/lib/debug/usr/bin/perl 15809
[snip]
(gdb) 

同时,由于将gdb附加到perl解释器,perl会被停止:

$ ./test.pl
pid: 15809
line 9
line 10
[snip]
line 9
line 10
line 9
[no further output]

现在,让我们回到gdb进行回溯:

(gdb) backtrace
#0  0x00007fd5b4479830 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007fd5b44796c0 in __sleep (seconds=<optimized out>) at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  0x00007fd5b4efc1e2 in Perl_pp_sleep (my_perl=0x1a91010) at pp_sys.c:4586
#3  0x00007fd5b4ea89b6 in Perl_runops_standard (my_perl=0x1a91010) at run.c:41
#4  0x00007fd5b4e4a585 in S_run_body (oldscope=1, my_perl=0x1a91010) at perl.c:2350
#5  perl_run (my_perl=0x1a91010) at perl.c:2268
#6  0x0000000000400f89 in main (argc=2, argv=0x7fff4de87628, env=0x7fff4de87640) at perlmain.c:120

很可能,perl恰好在睡眠中停止了()。但是哪一个?

现在我们需要确定在哪里查找当前正在执行的(Perl)源文件和行的perl内部信息。最初我找到了一些相关信息in the doumentation of mod_perl。在那里寻找curinfo宏。

(gdb) p my_perl->Icurcop->cop_file 
$1 = 0x1abd810 "./test.pl"
(gdb) p my_perl->Icurcop->cop_line 
$2 = 9

正如我们所看到的,我们在test.pl的第9行 - 正如预期的那样基于脚本的输出。

链接文档提到了有关线程/非线程perl二进制文件的一些区别(上面的例子是针对线程perl,v5.14.2)。它看起来有点过时了,因为它谈到了my_perl->Tcurcop,而我找到了我想要的my_perl->Icurcop名称。目前,我对perl的内部结构并不熟悉,无法解释为何重命名。

我希望这会有所帮助。

答案 1 :(得分:1)

我知道你说你不能重新启动脚本,但是如果你重新启动它,而不是记录,尝试使用Signal :: StackTrace或类似的,以便下次发生时你将能够使用USR2命中进程并获得堆栈跟踪转储。