Skip Menu |
 

This queue is for tickets about the Net-Server CPAN distribution.

Report information
The Basics
Id: 89519
Status: open
Priority: 0/
Queue: Net-Server

People
Owner: Nobody in particular
Requestors: FGA [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.007
Fixed in: (no value)



Subject: No way to get at fatal exceptions from children when using setsid
Download (untitled) / with headers
text/plain 1.3k
Hi, We're finishing up a project using Net::Server and during final debugging the issue came up that when children throw unhandled exceptions, there is no way to know about them. Currently the exceptions in children thrown from process_request are handled like this: my $ok = eval { $self->run_client_connection; 1 }; if (! $ok) { print $write "$$ exiting\n"; die $@; } This means the exception only ever appears in STDERR, which is for all purposes and intents invisible when using setsid (as we do by default). I've tried writing a custom __DIE__ handler but that is rarely a perfect solution... (at least it gets the exception into the logs) I think ideally the die $@ should be replaced by a customizable hook such as (simplified, probably) sub child_exception_hook { die $_[0]; } which would leave the option for users to do e.g. (also simplified) package MyDaemon; sub child_exception_hook { my $exception = shift; if ($exception =~ m/expected/) { Log::Log4perl->get_logger->warning('known exception: foobar'); } else { Log::Log4perl->get_logger->fatal("unhandled exception! message: $exception"); # rethrow and really die die $exception; # or maybe even notify the parent that this is really a # terminal condition and we should abort everything } } What do you think? I'm willing to write the patch if necessary.
Subject: Re: [rt.cpan.org #89519] No way to get at fatal exceptions from children when using setsid
Date: Tue, 15 Oct 2013 07:37:03 -0600
To: bug-Net-Server [...] rt.cpan.org
From: Paul Seamons <paul [...] seamons.com>
I think this is a great idea. I'll get something along these lines into the next version. Paul On 10/15/2013 03:27 AM, Fabrice Gabolde via RT wrote: Show quoted text
> Tue Oct 15 05:27:52 2013: Request 89519 was acted upon. > Transaction: Ticket created by FGA > Queue: Net-Server > Subject: No way to get at fatal exceptions from children when using setsid > Broken in: 2.007 > Severity: Normal > Owner: Nobody > Requestors: FGA@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=89519 > > > > Hi, > > We're finishing up a project using Net::Server and during final > debugging the issue came up that when children throw unhandled > exceptions, there is no way to know about them. > > Currently the exceptions in children thrown from process_request > are handled like this: > > my $ok = eval { $self->run_client_connection; 1 }; > if (! $ok) { > print $write "$$ exiting\n"; > die $@; > } > > This means the exception only ever appears in STDERR, which is > for all purposes and intents invisible when using setsid (as we > do by default). I've tried writing a custom __DIE__ handler but > that is rarely a perfect solution... (at least it gets the > exception into the logs) > > I think ideally the die $@ should be replaced by a customizable > hook such as (simplified, probably) > > sub child_exception_hook { > die $_[0]; > } > > which would leave the option for users to do e.g. (also > simplified) > > package MyDaemon; > > sub child_exception_hook { > my $exception = shift; > if ($exception =~ m/expected/) { > Log::Log4perl->get_logger->warning('known exception: foobar'); > } else { > Log::Log4perl->get_logger->fatal("unhandled exception! message: $exception"); > # rethrow and really die > die $exception; > # or maybe even notify the parent that this is really a > # terminal condition and we should abort everything > } > } > > What do you think? > > I'm willing to write the patch if necessary. >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.