🚀 go-pugleaf

In article <C0GEEn.FKD@agora.rain.com> rgrimes@agora.rain.com (Rodney Grimes) writes:
>Hi,
>I am trying to get XNTP V3 running on a SVR4 system.  I got it to
>compile and I can talk to it with xntpdc and ntpq.  It seems to 
>come up and get the time from the servers I have listed and then
>it just sits, it never seems to talk to the other servers again.

I haven't looked at XNTP V3 yet, but we had problems with XNTP V2 on SVR4
because of socket operations being done from the SIGIO handler.  On SVR4,
SIGIO is defined as SIGPOLL.  Due to the design of the socket emulation 
package, the socket library uses SIGPOLL for its own purposes, and there is a 
bizarre sequence of events that can cause you to come out of the signal 
handler for SIGIO with SIGIO held.  It's something like:

	sigset(SIGIO, input_handler)
	...
	input_handler() (called due to SIGIO) at this point, SIGIO is SIG_HOLD,
		because you are in the handler
	recvfrom()
		-- set SIGPOLL to SIG_IGN and save the old value
		-- do socket stuff
		-- reset SIGIO to old value, which is SIG_HOLD
	return from input_handler with SIGIO held

This is bad, because you will never find out about messages on your sockets
again.  The fix was to do a sigset(SIGIO, handler) before exiting the SIGIO
handler.  Sigrelse(SIGIO) might work too, but I don't remember the exact
details anymore.

As I said, I haven't looked at XNTP V3, so this may be useless information,
but we did see similar problems with V2, so you may want to look for this
sort of behavior.  I believe that ntpdate had a similar problem.

Good luck,
-- Steve
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea