Thanks all!
My script is a socket client talking to a mainframe-based server. There is
database processing involved on the mainframe side and MQ involved on the
client side.
I want my script to be in a continuous loop with a 30 second pause. While
it is 'working' I want to delay kill signal from a user (root in this
case) until it has reached a 'safe' point. This is not very different
from the 'transaction logic' we encounter in database processing. If the
script is killed mid-flight, it would be time-consuming to investigate and
re-start.
How does one program for such a situation?
"Federico Lucifredi" <[EMAIL PROTECTED]>
06/02/2004 09:24 AM
To: "Boston List" <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>, "Ranga Nathan" <[EMAIL PROTECTED]>
cc:
Subject: Re: [Boston.pm] Completing processing before
SIGHUP
Hello There,
> The book also states that you can not IGNORE or trap a A KILL or STOP
> signal. Is it still the case with Perl 5.8 and Linux kernel 2.4x?
That's a fact of *NIX life I am afraid: KILL is unstoppable (ignore), as
is
SIGSTOP - they provide the user/admin with a "surefire way of either
killing
or stopping a process" --Stevens.
And, as catching these would also enable you to ignore them, you cannot do
that either!
I did not read the whole thread, but if you are doing more than just
handling error conditions/froceful termination from the kernel, you should
be aware that signals hanve slightly different behaviors across the *NIX
spectrum. This is particularly relevant if you take to blocking them, or
if
you want them to interrupt/restart the so called "slow system calls".
-Federico
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
Muad'Dib of Caladan (Federico L. Lucifredi)- [EMAIL PROTECTED],
http://www.lucifredi.com
----- Original Message -----
From: "Ranga Nathan" <[EMAIL PROTECTED]>
To: "Boston List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, June 02, 2004 0:34
Subject: Re: [Boston.pm] Completing processing before SIGHUP
> Thanks Andrew for the explanation... but
>
> I just read the signals section of Programming Perl 2nd edition (my
> precious book with Larry Walls autograph, camel stamp and TMTOWTDI
stamp)
> which cautions against doing anything worthwhile after handling a
signal,
> since the underlying C routines are not re-entrant on most platforms. In
> my case there is only one instance of the script required to run at any
> time (ha ha, soon there will pop up an exception!) , so it is OK.
>
> The book also states that you can not IGNORE or trap a A KILL or STOP
> signal. Is it still the case with Perl 5.8 and Linux kernel 2.4x?
>
>
> #+++++++++++++++++++++= Lastly ++++++++++++++++++++++++#
> Ronald, Could we please set the Reply-To: to the mailing list address
> please, pretty please?
> #++++++++++++++++++++++++++++++++++++++++++++++++++++#
> Thanks
>
>
>
>
> Andrew Langmead <[EMAIL PROTECTED]>
>
> Sent by: [EMAIL PROTECTED]
> 05/31/2004 04:59 PM
>
> To: Ranga Nathan <[EMAIL PROTECTED]>
> cc: Boston List <[EMAIL PROTECTED]>
> Subject: Re: [Boston.pm] Completing processing before
> SIGHUP
>
>
> On May 31, 2004, at 3:33 PM, Ranga Nathan wrote:
>
> > Andrew Langmead <[EMAIL PROTECTED]>
> > You should probably get your hands on a copy of Advanced Programming
in
> > the UNIX Environment
> > <http://www.aw-bc.com/catalog/academic/product/0,,0201563177,00%2ben-
> > USS_01DBC.html> by W. Richard Stevens. It is one of the best
> > references I have seen for how the OS intereracts with applications
for
> > matters like this.
>
> [stuff deleted. I probably could have deleted the above too, but it is
> a great book and I wanted the opportunity to recommend it again.]
>
> > You can set your $SIG{HUP} handler in a manner like: "my $hangup = 0;
> > $SIG{HUP} = sub { $hangup=1 };" and then check if the value of $hangup
> > changes.
> >
> > This implies that normal execution continues have the HUP is handled
> > and
> > it is the application responsibility to recognize the change to the
> > variable. Am I reading it right? If so this is the exact behaviour I
> > want.
> > so long as the execution resumes after the signal handling, it is up
to
> > the application to do whatever it can to reach a stable state and then
> > terminate.
>
> Yes. Nearly every signal can be blocked, caught, or left to its default
> action. The default action for most signals is to terminate the
> process, which is the behavior you are used to seeing. If the signal
> is caught, the normal execution of your program is put aside, the
> signal handler run, and then you program resumes as normal. A signal
> handler is sort of like a subroutine that your program ran but wasn't
> expecting. Or if you at all familiar with a lower level form of
> programming, signals and signal handlers act almost exactly like
> interrupt service routines that a hardware device driver would handle.
>
> _______________________________________________
> Boston-pm mailing list
> [EMAIL PROTECTED]
> http://mail.pm.org/mailman/listinfo/boston-pm
>
> _______________________________________________
> Boston-pm mailing list
> [EMAIL PROTECTED]
> http://mail.pm.org/mailman/listinfo/boston-pm
>
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
