Mod_perl and Signals

[janedunnie]

Hi,

I'm in the process of transferring code to a new Linux machine, with a
newer version of Perl (Perl 5.8.5), and also cleaning up the code to
run under mod_perl. However, I'm having problems with some code that
I've previously used, which no longer appears to work under the new
config. I understand from scouring the web that signal handling
changed in 5.8+, but despite trying every method I could find, I still
can't get it to work under mod_perl. However, each method works
outside of mod_perl.

The original code was similar to this:

eval
{
local $SIG{ALRM} = sub {die "alarm\n"};
alarm 5;
system('some command');
alarm (0);
};


New code which I've tried under 5.8, and which works outside of
mod_perl, includes the following:

use POSIX qw(SIGALRM);
POSIX::sigaction(SIGALRM, POSIX::SigAction->new(sub{die "alarm"})) or
die "Error setting SIGALRM handler: $!\n";

eval{
alarm 5;
system('some command');
alarm (0);
};

POSIX::sigaction(SIGALRM, $oldaction);


Other new code which I've tried, and which also works outside of
mod_perl, is as follows:

use Sys::SigAction qw(timeout_call);

if (timeout_call(5, sub{my $retval=&test();}))
{
print "timed out\n";
};

sub test{
system('some command');
}


When I say that these methods "don't work" under mod_perl I mean that
the processes simply continue without waiting for the alarm. They
don't error ... they just don't wait for the specified command(s) to
finish.

So, I'm wondering what kind of work-around there may be, or what
alternative method of handling time-outs may exist in mod_perl under
5.8.x.

Any assistance much appreciated.

Thanks!
Jane

 

[J. Gleixner]

Hi,

I'm in the process of transferring code to a new Linux machine, with a
newer version of Perl (Perl 5.8.5), and also cleaning up the code to
run under mod_perl. However, I'm having problems with some code that
I've previously used, which no longer appears to work under the new
config. I understand from scouring the web that signal handling
changed in 5.8+, but despite trying every method I could find, I still
can't get it to work under mod_perl. However, each method works
outside of mod_perl.

The original code was similar to this:

eval
{
local $SIG{ALRM} = sub {die "alarm\n"};
alarm 5;
system('some command');
alarm (0);
}; [...]
So, I'm wondering what kind of work-around there may be, or what
alternative method of handling time-outs may exist in mod_perl under
5.8.x.

Any assistance much appreciated.

Doing a simple search on the Internet showed that this was discussed
extensively back in 2004. It's Apache 2, not perl. In short,
using prefork MPM should work, or Apache 1.3. No idea if this is
still the case with the latest version of Apache, however
looking through Apache 2 documentation on signals/threads
should cover it or asking on an Apache related newsgroup.

http://marc.info/?t=110175278300007&r=1&w=2

 

[xhoster]

Hi,

I'm in the process of transferring code to a new Linux machine, with a
newer version of Perl (Perl 5.8.5), and also cleaning up the code to
run under mod_perl. However, I'm having problems with some code that
I've previously used, which no longer appears to work under the new
config. I understand from scouring the web that signal handling
changed in 5.8+, but despite trying every method I could find, I still
can't get it to work under mod_perl. However, each method works
outside of mod_perl.

What do you mean by each method? Does the entire thing as a whole work
outside of mod_perl under 5.8.5?

The original code was similar to this:

eval
{
local $SIG{ALRM} = sub {die "alarm\n"};
alarm 5;
system('some command');
alarm (0);
};

New code which I've tried under 5.8, and which works outside of
mod_perl, includes the following:

What does the old code do under 5.8.5 outside of mod_perl?

use POSIX qw(SIGALRM);
POSIX::sigaction(SIGALRM, POSIX::SigAction->new(sub{die "alarm"})) or
die "Error setting SIGALRM handler: $!\n";

eval{
alarm 5;
system('some command');
alarm (0);
};

POSIX::sigaction(SIGALRM, $oldaction);

Where does $oldaction get set?

Other new code which I've tried, and which also works outside of
mod_perl, is as follows:

use Sys::SigAction qw(timeout_call);

if (timeout_call(5, sub{my $retval=&test();}))
{
print "timed out\n";
};

sub test{
system('some command');
}

When I say that these methods "don't work" under mod_perl I mean that
the processes simply continue without waiting for the alarm.

They aren't supposed to wait for the alarm. alarms are what happens when
you are waiting for something *else*.

They
don't error ... they just don't wait for the specified command(s) to
finish.

What is the return value of Perl's system function? How do you know
that it is not waiting? Can you produce a runnable, self-diagnosing script
and show us the results you get from it, rather than your intepretation of
those results? Replacing system('some command') with, for example:

print "before time is ", time(), "<br>";
print "system returned with ", system ("sleep 20"), "<br>";
print "after time is ", time(), "<br>";

Xho

 

[janedunnie]

What do you mean by each method? Does the entire thing as a whole work
outside of mod_perl under 5.8.5?

"Each method" = each of the different ways that I've tried this. Yes,
the entire thing as a whole works outside of mod_perl under 5.8.5.

What does the old code do under 5.8.5 outside of mod_perl?

Runs a couple of other jobs, which may or may not complete within the
alarm time. If one of them does not complete then the alarm will
"ring." ... which is fine, and I carry on my merry way without
worrying about the result. On the other hand they may both complete
within the time provided and in which case I'll get to the next part
of the script more quickly.

Where does $oldaction get set?

Forget it ... I inadvertently pasted some code from another version of
my attempts. It's unrelated to the code directly above it.

They aren't supposed to wait for the alarm. alarms are what happens when you are waiting for something *else*.

Yes, exactly. I am waiting for "some command" to finish.

How do you know that it is not waiting? Can you produce a runnable, self-diagnosing script ...etc.

Having spent a day testing it, I can vouch for it not waiting. Yes,
I've done all the self-diagnosing scripts etc, with start-time, end-
time, etc, etc.


Thanks.

 

[janedunnie]

Per' the comments from J. Gleixner, above, yes, I can see that it's an
Apache2 problem now, as opposed to Perl ... Thanks.

Re' my previous comments, then I should have clarified that when I
said I was running it out of mod_perl, and it worked, that I was
running it from the command line ... where Apache obviously isn't
involved at all ... and hence why it worked.

Thanks to all ... Will need to take a look at prefork MPM.

Jane