4

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

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

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

4

2 回答 2

7

一种可能的方法是使用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 恰好在 sleep() 的中间停止。但是哪一个？

现在我们需要弄清楚在哪里可以找到关于当前正在执行的 (Perl) 源文件和行的 perl 内部信息。最初我在 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 的内部结构还不够熟悉，无法解释为什么它会被重命名。

我希望这有帮助。

于 2012-07-07T14:42:05.250 回答
1

我知道您说您无法重新启动脚本，但是如果您确实要重新启动它一次，而不是记录，请尝试使用 Signal::StackTrace 或类似方法，以便下次发生这种情况时您可以使用USR2 并获取堆栈跟踪转储。

于 2012-04-29T12:02:11.933 回答