[Techtalk] debugging perl scripts

Almut Behrens almut-behrens at gmx.net
Sat Aug 28 11:36:35 EST 2004


On Fri, Aug 27, 2004 at 11:15:51PM -0400, overhaul wrote:
> Hi everyone...   been pretty quiet around here lately!  I'm hoping it 
> isn't a total ghost town and someone's still reading.  :)

hm, maybe we're no longer having any problems... or we're all on
vacation (at least I was... :)

> 
> I have been trying to track down why a certain perl script tends to hang 
> or die leaving behind it's children
> 
> this script doesn't log anywhere so I have no way of knowing what it's 
> doing when it dies...  the children , however keep on running ..  how 
> can I debug a process that is already  running?

You could try attaching strace to the running process:

  strace [-f] -p <PID-of-process-to-debug>

This traces system calls, which might give you an idea about files it
tries to access that don't exist, and stuff like that.
Even if there's no directly useful info, it might still help to know
what the program does (system-call-wise) immediately before failing,
to roughly locate at which point it dies.

If it's a daemon, stderr and stdout usually get closed, so the program
can no longer tell you why it dies.  So, you could look for where in
the code STDERR gets closed, uncomment that statement, and then leave
some terminal attached where the program can print to...  Some daemons
even have a commandline option to prevent them from daemonizing, for
debugging purposes (thus having them stay in the foreground)...
If you tell us a bit more about the script, and the circumstances under
which it dies, we might perhaps have some more ideas :)

Perl deamons sometimes die because of stupid little things like
"$ref->{key} = $val;", presuming that for example, due to some error,
$ref is set to an array reference.  Perl would die with "Can't coerce
array into hash", but it can't tell you when stderr is closed...

Good luck,
Almut



More information about the Techtalk mailing list