tr@ctt.bellcore.com (tom reingold) (06/25/89)
On one of our two Pyramids, users get biff messages for other users. I think this is comsat's fault, but I can't check because Pyramid's source code is priced out of this world. I can't imagine why they would hack comsat. Any ideas? Yours eternally grateful, Tom Reingold |INTERNET: tr@ctt.bellcore.com Bell Communications Research |UUCP: bellcore!ctt!tr 444 Hoes La room 1E225 |PHONE: (201) 699-7058 [work], Piscataway, NJ 08854 | (201) 287-2345 [home]
csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/25/89)
In article <17033@bellcore.bellcore.com> tr@ctt.bellcore.com (tom reingold) writes: >On one of our two Pyramids, users get biff messages for other users. Yeah, this seems to happen from time to time, in little bursts. I'm not sure what causes it. The folks at Cal Poly have narrowed it down quite a bit; if I could find an environment where it occurs consistently I could nail it. We're running the plain 4.3BSD comsat, with no hacking done to it, so it's probably some kind of portability problem, e.g., dereferencing a NULL pointer. It is definitely a problem in scanning /etc/utmp. >... but I can't check because Pyramid's source code is priced out of this >world. I thought we pretty much charged what AT&T does....? I don't know for sure. Some of it we won't sell at all any more; too much risk at having enhance- ments like virtual disk suddenly appear in other people's machines. <csg>
roskuski@mirror.UUCP (Barry Roskuski) (06/26/89)
In article <17033@bellcore.bellcore.com> tr@ctt.bellcore.com (tom reingold) writes: >On one of our two Pyramids, users get biff messages for other users. I >think this is comsat's fault, but I can't check because Pyramid's We have had 2 problems at our site. The one you describe, and people not getting biff'ed at all when they should be. Apparently, the SIGALRM that comsat uses to keep it's list of logged on users up to date stops going off for an unexplained reason, and the configuration gets 'frozen' (In our case, the *other users* that the people get biff'ed for are people who were logged on to the terminal at some point in the past). A "kill -ALRM pid" (where pid is the pid of comsat) puts it back in synch. Hope this helps. ------------------------------------------------------------------------------ Barry J. Roskuski Mirror Systems 2067 Massachusetts Ave. Cambridge, MA 01240 roskuski@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!roskuski
hoyt@polyslo.CalPoly.EDU (Sir Hoyt) (06/27/89)
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
beard@spam.ua.oz (David Beard) (06/27/89)
In article <74984@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > In article <17033@bellcore.bellcore.com> tr@ctt.bellcore.com (tom reingold) writes: >>On one of our two Pyramids, users get biff messages for other users. > > Yeah, this seems to happen from time to time, in little bursts. I'm not sure > what causes it. The folks at Cal Poly have narrowed it down quite a bit; if I > could find an environment where it occurs consistently I could nail it. We're > running the plain 4.3BSD comsat, with no hacking done to it, so it's probably > some kind of portability problem, e.g., dereferencing a NULL pointer. It is > definitely a problem in scanning /etc/utmp. We had that problem on our Pyramid 9820 system here at Adelaide University a few months ago after we upgraded from OSx4.0 to 4.4. One of the changes in 4.4 was a fix that supported more than 64 pseudo terminal devices. To take advantage of this, I created extra pty's (using makedev) and included the new devices in /etc/ttys /etc/ttytype and /etc/u_ttytype. What I forgot to do was add entries in /etc/inittab. After fixing this, the problem disappeared. Hope this helps. -- beard@spam.ua.oz.au David Beard University of Adelaide GPO Box 498 Adelaide South Australia, 5001