Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!polyslo!hoyt
From: hoyt@polyslo.CalPoly.EDU (Sir Hoyt)
Newsgroups: comp.sys.pyramid
Subject: Re: comsat and biff
Message-ID: <12147@polyslo.CalPoly.EDU>
Date: 26 Jun 89 21:34:43 GMT
References: <17033@bellcore.bellcore.com> <74984@pyramid.pyramid.com>
Reply-To: hoyt@polyslo.CalPoly.EDU (Sir Hoyt)
Organization: WanderLand, San Luis Obispo
Lines: 27

In <74984@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>some kind of portability problem, e.g., dereferencing a NULL pointer. It is
>definitely a problem in scanning /etc/utmp.

	I found the problem ot be with SIGALRMs.  That is
	comsat sets it up so that it gets a SIGALRM every now
	and then ( can't remember the exact time interval ).
	When comsat gets the SIGALRM it does the following:

		1) See if it has been idel, if so die.
		2) Check to see if utmp has change.

	Now what seems to happen some how the SIGALRM that 
	comsat sets up gets lost.  How this happens I do not
	know, the code looks right to me ( which does not mean much ).

	To tell if this is whats happening find out the pid
	of the current comsat, then after about 10 mintues
	check it again.  If they match, send comsat a SIGARLM.
	If comsat the disapears, then this is your problem.


-- 
John H. Pochmara				 A career is great, 
UUCP: {csun,voder,trwind}!polyslo!hoyt		 But you can't run your 
Internet: hoyt@polyslo.CalPoly.EDU		 fingers through its hair
							-Graffiti 4/13/83