Description of problem:
The updated 'rdate' in Fedora Core 1 adds an alarm() call to cause a 
10 second timeout to occur.  However, the alarm is not handled, which 
causes calling programs to abort up the process tree under some 
circumstances.  Adding a trivial signal handler fixes the problem

This situation occurs when the client system attempts to rdate from a 
server whose default input iptable policy is 'drop' (ie, blackhole).

Version-Release number of selected component (if applicable):
1.3.3

How reproducible:
always


Steps to Reproduce:
1. block incoming rdate queries with iptables on the server side
     iptables -I INPUT -m tcp -p tcp --dport 37 -j DROP
2. try to rdate on the client side, querying the server
3.
  
Actual results:

The rdate call returns with a 'Alarm' message and error 142.  The 
message isn't on stdout or stderr, which frequently blows up calling 
shell scripts that run from the system startup.

Expected results:

rdate should only return on stdout/stderr so it can be wrappered in 
shell scripts etc.

Additional info:

In rdate.c add a trivial signal handler to handle the alarm.

#include <signal.h>
void  ALARMhandler(int sig) { exit(sig); } 
[...then down below their alarm(10) call...]
signal(SIGALRM, ALARMhandler);