Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > SIgnal help

Reply
Thread Tools

SIgnal help

 
 
Dave Saville
Guest
Posts: n/a
 
      10-26-2013
I am developing a script that uses Net:ing

I need to be able to CTRL-C it and have my END block run.

I have $SIG{INT} = \&catch; at the top of the script;

sub catch
{
$int++;
$SIG{INT} = 'DEFAULT' if $int > 3;
}


In the main program I check for $int being no-zero and exit.
The actual ping is issued from a subroutine.

If the other end is responding then a CTRL-C will stop it and run my
END block. However if the other end is *not* responding then I get
this:

..........

CTRL-C Nothing happens, if I leave it it stays that way and no more
output appears.

CTRL-C
Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
16 at D:/u
sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.

Followed by the print from my END block.

What's going on and what have I missed? I am guessing that the
Net:ing code has installed another handler?

TIA
--
Regards
Dave Saville
 
Reply With Quote
 
 
 
 
Dave Saville
Guest
Posts: n/a
 
      10-27-2013
On Sat, 26 Oct 2013 20:01:15 UTC, Ben Morrow <(E-Mail Removed)> wrote:

Hi Ben

>
> Quoth "Dave Saville" <(E-Mail Removed)>:
> > I am developing a script that uses Net:ing
> >
> > I need to be able to CTRL-C it and have my END block run.
> >
> > I have $SIG{INT} = \&catch; at the top of the script;
> >
> > sub catch
> > {
> > $int++;
> > $SIG{INT} = 'DEFAULT' if $int > 3;
> > }
> >
> >
> > In the main program I check for $int being no-zero and exit.
> > The actual ping is issued from a subroutine.
> >
> > If the other end is responding then a CTRL-C will stop it and run my
> > END block. However if the other end is *not* responding then I get
> > this:
> >
> > .........
> >
> > CTRL-C Nothing happens, if I leave it it stays that way and no more
> > output appears.
> >
> > CTRL-C
> > Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
> > 16 at D:/u
> > sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.
> >
> > Followed by the print from my END block.
> >
> > What's going on and what have I missed? I am guessing that the
> > Net:ing code has installed another handler?

>
> Net:ing does not install a SIGINT handler. You may be falling foul of
> 'safe signals', or this may be an inconsistency in the way OS/2 handles
> signals. I can't reproduce this with this program:
>
> use 5.012;
> use Net:ing;
>
> my $int = 0;
> $SIG{INT} = sub {
> warn "SIGINT ($int)";
> if (++$int > 3) {
> warn "CLEARING SIGINT";
> $SIG{INT} = "DEFAULT";
> }
> };
>
> $| = 1;
> my $P = Net:ing->new;
> while (1) {
> print "SENDING PING...";
> my $p = $P->ping($ARGV[0]);
> say $p ? "ALIVE" : "DEAD";
> sleep 5;
> }
>
> even if I time the ^C so it comes while a ping is in progress, which
> suggests the latter; can you post a minimal program which exhibits the
> problem to confirm whether this is OS-dependent?


Running the above on 5.16.0

[T:\tmp]try.pl 192.168.0.2
SENDING PING...ALIVE
SIGINT (0) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (1) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (2) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (3) at try.pl line 6.
CLEARING SIGINT at try.pl line 8.
SENDING PING...ALIVE

[T:\tmp]try.pl 192.168.0.5
SENDING PING...DEAD
SENDING PING...SIGINT (0) at try.pl line 6.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD
SENDING PING...SIGINT (1) at try.pl line 6.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD
SIGINT (2) at try.pl line 6.
SENDING PING...SIGINT (3) at try.pl line 6.
CLEARING SIGINT at try.pl line 8.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD

And another thing

A "real" ping seems to be about once a second here. If I start a ping
to a host, let it return a few times and pull the ethernet cable it
obviously stops printing returns.If I then put the cable back it
starts again. CTRL-C and I get a summary of pings sent, received and
lost.

Trying to do the same thing with Net:ing and it stops printing
returns and starts again when I replace the cable - but it sees *no*
dropped packets. It would appear that it blocks until it gets a
return. I just tried your program doing the same thing and it hangs at
SENDING PING... until I plug it in again when it takes almost 20
seconds before it prints ALIVE.


--
Regards
Dave Saville
 
Reply With Quote
 
 
 
 
Dave Saville
Guest
Posts: n/a
 
      10-27-2013
I just tried my script again under 5.16.0 and it is OK with CTRL-C
when pinging a non exisitant IP. So it is something in my "normal use"
5.8.2 perl Net:ing or the underlying socket code.

5.8.2 Net:ing is version 2.31 and 5.16.0 is 2.38 - Diff shows a lot
of changes.

However, the "pulling the plug hang" remains under 5.16.0.
--
Regards
Dave Saville
 
Reply With Quote
 
Dave Saville
Guest
Posts: n/a
 
      10-27-2013
On Sun, 27 Oct 2013 12:47:53 UTC, Ben Morrow <(E-Mail Removed)> wrote:

<snip>

> I get the same results, so there's something different about your
> program which is causing the hang and the failed unpack_sockaddr_in. You
> will need to start cutting it down until you get something small enough
> to post.


As I said in another reply it would seem to the difference between
5.8.2 and 5.16.0

>
> > And another thing
> >
> > A "real" ping seems to be about once a second here. If I start a ping
> > to a host, let it return a few times and pull the ethernet cable it
> > obviously stops printing returns.If I then put the cable back it
> > starts again. CTRL-C and I get a summary of pings sent, received and
> > lost.
> >
> > Trying to do the same thing with Net:ing and it stops printing
> > returns and starts again when I replace the cable - but it sees *no*
> > dropped packets. It would appear that it blocks until it gets a
> > return. I just tried your program doing the same thing and it hangs at
> > SENDING PING... until I plug it in again when it takes almost 20
> > seconds before it prints ALIVE.

>
> ping(1) sends ICMP pings by default, which (at least on Unix) require
> privilege. In order to avoid making you run your script as root,
> Net:ing uses TCP 'pings' by default, which actually just attempt a TCP
> connection to the echo port (port 4) and return 'reachable' if either
> the connection succeeds or we get a definite ECONNREFUSED. This will
> lead to different behaviour on failure: in particular, a TCP connection
> attempt can take several minutes to time out, so if you pull the cable
> it will take that long before the host is reported dead. The delay when
> the cable is plugged back in is likely due to the kernel's exponential
> backoff of connection retries.
>
> I don't know what OS/2's security model is like.


Hasn't got one

I *am* using ICMP. My point is "real" ping gets a reject or something
when the cable is pulled but keeps trying as when it is plugged in
again it not only starts printing status lines immediately but also
knows how many failed. I know it is still pinging because the lights
on the switch blink.

PC <cable> switch <cable> router ie I pull the second cable.

I slowly modifed your code to match mine and it behaves as "real" ping
all the time. Just tried mine again and it worked. Hmmm.

I<snip>

> You could also try Net:ing::External, though again you will need to
> patch it for OS/2. (Or, you know, you could just run 'ping -c1' or
> whatever the equivalent is and check the exit status.)


LOL that was my first thought. The actual problem I am trying to solve
is a drop out on VOIP. It has been suggested to run a ping during the
call to see if packets are dropping or getting long response times.
Ping on its own only gives the packet loss at program end. I wanted it
continuous and thought running a completely fresh copy of ping every
second was a bit much.

--
Regards
Dave Saville
 
Reply With Quote
 
Dave Saville
Guest
Posts: n/a
 
      10-27-2013
Hi Ben

It would seem to be a timing issue. Using your code from previous post
I can reprduce the error.

SENDING PING... <timeout delay> DEAD
<sleep delay>
SENDING PING...

If you CTRL-C during the sleep delay it works as expected but if you
do it during the timeout delay you get the error. As I was running
with a sleep of 1 it was always in the timeout delay. Works OK on
5.16.0. You can CTLR-C any time and no error


--
Regards
Dave Saville
 
Reply With Quote
 
C.DeRykus
Guest
Posts: n/a
 
      10-27-2013
On Saturday, October 26, 2013 2:54:01 AM UTC-7, Dave Saville wrote:

[ ... ]
>
> CTRL-C
>
> Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be 16 at D:/u
>
> sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.
>


Not to minimize all the nuances but there was a
distinct feeling of "deja vu all over again" on
seeing that particular Socket.pm error. It may be of
interest to google the message (and some of the early
patches) since it was problematic for Net:ing and
other modules of that era

--
Charles DeRykus
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Target of signal assignment is not a signal" Nicolas Moreau VHDL 9 07-25-2007 04:21 PM
Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal Weng Tianxiang VHDL 2 01-30-2007 12:58 PM
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM



Advertisments