[SUMMARY] comsat and DU3.2c

From: Christopher C. Stevenson <csteven_at_kelvin.physics.mun.ca>
Date: Tue, 4 Jun 1996 10:59:00 -0230 (NDT)

Apologies for the late second summary; I was away for the weekend. A few more
very useful replies came my way regarding this problem ( to recap: comsat
went wild on our DU3.2c 3400S a short while ago and even removing all
processes owned by that user wouldn't prevent the uncontrolled spawning of
hundreds of comsats. This user happens to receive a large amount of
(legitimate) email, about 100-200 messages a day).

Thanks to the following people:

----------------------

"Paul M. Collison" <p.collison1_at_physics.oxford.ac.uk>

-It seemed to him that comsat was being confused by phantom logins and their
associated ttys. By phantom logins, it's meant the entries in utmp that
somehow fail to be updated when a user logs out (these show up as "logins"
when users type "w", for example. They're distinguished from real logins in
that they have no associated processes; "-"'s). Paul C's remedy was to shut
off comsat and avoid the problem this way:

"... comment [comsat] out of /etc/inetd.conf and kill -1 the inetd.
 My users use shell mail notification (set mail = mail spool file
 in ~/.login) and xbiff to be notified of new mail so it doesn't
 really hurt their way of working."

--------------------

Perhaps the be-all-and-end-all solution was proposed by
"Paul Gosse" <paulg_at_charon.ucs.mun.ca>

-He pointed me to a small C-code written by
"Paul Fardy" <pdf_at_plato.ucs.mun.ca>:

"While this may not be a solution for you, I will outline a possible way
that this can happen and a solution for it.

DU tends to end up with defunct processes lying around when the user does
not exit cleanly (or when the moon is full, or when ...). If a process that
grabs a tty is left as defunct, then ALL access to the tty will hang. Now
comsat will attempt to write to the FIRST tty that is sees a user logged in
on (via the utmp file). So if a shell is defunct and waiting on a signal
to exit, and it still has a utmp entry, comsat blocks in writing to it.

The solution we use is to remove the utmp entry/entries of the nasty
little processes. You may like to check for defunct processes and murder
them off (the ones whose parent is not init) about once a week. Tailor
that to the number of users you have. =)"

---------------------
-The author of the code has made it available to those interested, through
myself, himself or Paul Gosse. Does Digital plan a fix for the utmp problem
any time soon, incidentally? It causes grief on several levels, not the
least of which is confusion amongst new users trying to be "good" and not
leaving themselves logged-in.


Cheers,
Chris



======================================================
Christopher C Stevenson C3004 (709) 737-2624
Dept. of Physics & Physical Oceanography
Memorial University of Newfoundland
St. John's, Newfoundland, CANADA A1B 3X7
URL: http://www.physics.mun.ca/~csteven
Received on Tue Jun 04 1996 - 15:52:59 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT