grunwald@m.cs.uiuc.edu (12/13/88)
We're using `xdm' on an ultrix 2.2 based system and have the following problems that are probably caused by silly configuration problems, but I've been clueless on how to fix it. xdm exec's ~/.xsession. If this fails in some way, the clients for that session might be left running (this occured most recently when xmodmap barfed because of syntax errors). At other times, ``rogue xterms'' get unleashed on the system, sucking down an amazing amount of cpu cycles. In both cases, the problem seems to be left-over X clients when someone logs out. This vaxstaion (a color 3200) has a bad-rep in our group because these xterms are left hanging around by people getting used to X (& debugging their .twmrc files & xmodmaps). Is there a way to blast X clients at that point? Would killing the X server and restarting it be too much? Would that even do what I want? Dirk Grunwald Univ. of Illinois grunwald@m.cs.uiuc.edu
keith@EXPO.LCS.MIT.EDU (Keith Packard) (12/15/88)
> In both cases, the problem seems to be left-over X clients when someone logs > out. This vaxstaion (a color 3200) has a bad-rep in our group because these > xterms are left hanging around by people getting used to X (& debugging their > .twmrc files & xmodmaps). > Is there a way to blast X clients at that point? Would killing the X server > and restarting it be too much? Would that even do what I want? xdm does attempt to kill all of the clients when the session is over. It expects the X server to accept a SIGHUP and close all connections. The only trouble with this is that if the session exits quickly after spawning a collection of clients; some of those clients may end up connecting to the server after it has been reset. A very simple fix for this would be to have a reset script run after the session which simply sleeps for 10 seconds or so. This would have the unfortunate side-effect of delaying logout by 10 seconds in the normal case. Perhaps a better method would be to write a session which notices a quickly terminated client session and pauses only in that case. A short C program would suffice. The solution I am using here is a more general authorization scheme which prevents old clients from connecting to the server after the session terminates by changing the "password" used to access the server. Expect to hear more about this scheme in the coming weeks.