Signals and recvfrom() behavior

[Karl Robillard]

Hello,


I have a program which is waiting for data on a socket in recvfrom(). If a
signal (SIGTERM) is sent to the program, should recvfrom() return with
errno set to EINTR? It does not return on my system (Linux 2.4.18), but I
have seen older example code which checks for EINTR. Is there a way to
cause recvfrom() to return when a signal occurs?


-Karl Robillard

[shadows]

Karl Robillard [email]krobillard@cox.net[/email] wrote:

> I have a program which is waiting for data on a socket in recvfrom(). If a
> signal (SIGTERM) is sent to the program, should recvfrom() return with
> errno set to EINTR? It does not return on my system (Linux 2.4.18), but I
> have seen older example code which checks for EINTR. Is there a way to
> cause recvfrom() to return when a signal occurs?

If you are ignoring it then you won't interrupt the system
call. As a check, specifically unignore the signal before
recvfrom() and see what happens.

--
Thamer Al-Harbash [url]http://www.whitefang.com/[/url]

[David Schwartz]

"Karl Robillard" <krobillard@cox.net> wrote in message
news:%JgYa.63006$zy.45967@fed1read06...

> Hello,
>
>
> I have a program which is waiting for data on a socket in recvfrom(). If

a

> signal (SIGTERM) is sent to the program, should recvfrom() return with
> errno set to EINTR? It does not return on my system (Linux 2.4.18), but I
> have seen older example code which checks for EINTR. Is there a way to
> cause recvfrom() to return when a signal occurs?
>
>
> -Karl Robillard

It works for me:

$ cat sock.c

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

void die(const char *a)
{
fprintf(stderr, "%s\n", a);
exit(0);
}

int main(void)
{
int sock;
struct sockaddr_in ad;
sock=socket(AF_INET, SOCK_DGRAM, 0);
if(sock<0) die("Unable to get socket");
ad.sin_family=AF_INET;
ad.sin_port=0;
ad.sin_addr.s_addr=0;
if(bind(sock, (struct sockaddr *)&ad, sizeof(ad))!=0)
{
close(sock);
die("bind");
}
recvfrom(sock, &ad, sizeof(ad), 0, NULL, NULL);
}

$ gcc sock.c -o sock
$ ./sock
<pauses, from another console, I send this process a SIGTERM>
Terminated

Maybe you're doing something odd, like catching SIGTERM?

DS

[Karl Robillard]

David Schwartz wrote:

> $ gcc sock.c -o sock
> $ ./sock
> <pauses, from another console, I send this process a SIGTERM>
> Terminated
>
> Maybe you're doing something odd, like catching SIGTERM?
>
> DS

Thats just it. I am catching SIGTERM. However, I'd like the program to
continue from the recvfrom() call. The single line of documentation on
EINTR makes it sound as if recvfrom() will return when a signal occurs.
This does not seem to be the case.


-Karl

[Karl Robillard]

shadows wrote:

> Karl Robillard [email]krobillard@cox.net[/email] wrote:
>

>> I have a program which is waiting for data on a socket in recvfrom(). If
>> a signal (SIGTERM) is sent to the program, should recvfrom() return with
>> errno set to EINTR? It does not return on my system (Linux 2.4.18), but
>> I
>> have seen older example code which checks for EINTR. Is there a way to
>> cause recvfrom() to return when a signal occurs?

>
> If you are ignoring it then you won't interrupt the system
> call. As a check, specifically unignore the signal before
> recvfrom() and see what happens.
>

I am catching the signal. My signal handler is called but recvfrom()
continues to wait. Is there a way to get recvfrom() to return?


-Karl

[David Schwartz]

"Karl Robillard" <krobillard@cox.net> wrote in message
news:xJkYa.63275$zy.18740@fed1read06...

> I am catching the signal. My signal handler is called but recvfrom()
> continues to wait. Is there a way to get recvfrom() to return?

How are you catching the signal? With 'sigaction'?

Also, you can always 'longjmp' from the signal handler.

DS

[shadows]

Karl Robillard [email]krobillard@cox.net[/email] wrote:

> I am catching the signal. My signal handler is called but recvfrom()
> continues to wait. Is there a way to get recvfrom() to return?

OK that changes things. Are you using sigaction() or the older
signal()? sigaction will let you specify whether or not you want
restartable system calls. This is done via the SA_RESTART flag in
the struct sigaction you pass to sigaction(). Just make sure it's
cleared.

--
Thamer Al-Harbash [url]http://www.whitefang.com/[/url]

[Karl Robillard]

David Schwartz wrote:

>
> "Karl Robillard" <krobillard@cox.net> wrote in message
> news:xJkYa.63275$zy.18740@fed1read06...
>

>> I am catching the signal. My signal handler is called but recvfrom()
>> continues to wait. Is there a way to get recvfrom() to return?

>
> How are you catching the signal? With 'sigaction'?
>
> Also, you can always 'longjmp' from the signal handler.
>
> DS

David,


No, I'm using 'signal'. I simply need to catch SIGTERM to cleanly shut down
my program (write a shutdown message to a log file, etc.). Here's an
outline of my program flow:


term(){
running = false;
}

main(){
init_stuff();
socket();

running = true;
signal( SIGTERM, term() );

while( running ){
recvfrom();
process_data();
}

close();
cleanup_stuff();
}


If necessary, I'll cleanup everything and exit from the signal handler. The
description of EINTR in the recvfrom man page made me think that this
program flow would work. It does not, so I am wondering under what
conditions recvfrom() will return with errno set to EINTR. I was looking at
someone else's code where they use alarm() (SIGALRM) to break out of
recvfrom(). I wrote a test to do this but my code never exited from
recvfrom(). Can signals cause recvfrom() to return?


-Karl

[Karl Robillard]

shadows wrote:

> Karl Robillard [email]krobillard@cox.net[/email] wrote:
>

>> I am catching the signal. My signal handler is called but recvfrom()
>> continues to wait. Is there a way to get recvfrom() to return?

>
> OK that changes things. Are you using sigaction() or the older
> signal()? sigaction will let you specify whether or not you want
> restartable system calls. This is done via the SA_RESTART flag in
> the struct sigaction you pass to sigaction(). Just make sure it's
> cleared.
>

Using sigaction() rather than signal() gives the expected behavior. Thank
you Shadows (and David) for your help.

I have a dream that someday all man pages will clearly state, up front, that
a call is obsolete or deprecated.


Cheers,
-Karl

[David Schwartz]

"Karl Robillard" <krobillard@cox.net> wrote in message
news:ZxmYa.63288$zy.46938@fed1read06...

> > How are you catching the signal? With 'sigaction'?

> No, I'm using 'signal'. I simply need to catch SIGTERM to cleanly shut

down

> my program (write a shutdown message to a log file, etc.). Here's an
> outline of my program flow:

Do not use 'signal', use 'sigaction'. You are requesting BSD signal
semantics, which is definitely not what you want.

DS