wood@acf4.NYU.EDU (David Wood) (02/10/90)
Has anybody written a new xinit type tool for the X-terminals. I began this and got about half way there but thought I'd ask around in netland to see if anyone has already done this. The problem is that xinit always tries to run a server (or am I mistaken), but these X-terminals just need to have the .xinitrc (or .xsession) file started up. Then when the person is done, this knew xinit could do a killpg() to kill all the clients. That in fact is the problem I'm experiencing with the X-terminals. If you have novice user logout of one of these without killing all the clients they just hang around. Enough said, does anybody have any comments. Thanks. p.s. Perhaps it should be an extension to xinit. ------------------------------------------------------------------------- David Wood wood@acf2.nyu.edu New York University ...!uunet!cmcl2!wood 212-998-3029 "Brain. Brain. What is brain?" Kara the Eymorg, "Spock's Brain", Stardate 5432.3 -------------------------------------------------------------------------
jcarson@WILKINS.BCM.TMC.EDU (Janet L. Carson) (02/12/90)
Here's how we've solved the problem around here: For startup,
the .login plays around with $TERM and a few other things to
guess what you're on (a type of workstation or an X terminal).
To start on an X terminal, my script does a "sh .xinitrc" to start
up the same processes I run in a workstation environment, but
different people do different things.
The shutdown problem is worse than you thought... killpg will
*not* kill all of your clients in a heterogeneous environment, as
everything displaying on the same screen is not necessarily
running on the same machine. (And frequently isn't around here!)
Moreover, even if you are only using one machine to start all of
your clients from, they are not always all in the same process group.
I've developed a "shutdown" program which basically walks through
the window tree shutting down clients. It identifies application
top-level windows by looking for the WM_STATE variable, then checks
WM_PROTOCOLS. If the client supports WM_DELETE_WINDOW, I send that
message. Otherwise, I do an XKillClient on it. (I have an error
handler catch me if an application has multiple windows and I try to
kill it twice.) I sleep for a while, then walk through again, doing
an XKillClient on anything still surviving. (The second pass doesn't
seem to get executed when the window manager is twm, but seems to be
necessary to kill swm when I use that window manager.)
I've tried to follow ICCCM standards, but I'm not sure whether this
is really a "nice" application to have around. I can send you a
copy if you are interested in looking at it.
--Janet
Janet L. Carson internet: jcarson@bcm.tmc.edu
Baylor College of Medicine uucp: {rutgers,mailrus}!bcm!jcarsoned@lupine.UUCP (Ed Basart) (02/12/90)
If you want a nice way to allow your X terminals to get started, plus provide automatic shutdown when the terminal is powered off, you need XDMCP. This is provided as part of R4. The 2.1 release from NCD provides XDMCP support. If you aren't so lucky to have XDMCP support at hand, you can still use R3 XDM. There is one hickup in that xdm won't recognize a re-powered-up X terminal. There has been a hack posted to the net which fixes this. Ed Basart ed@ncd.com -- Ed Basart, 350 N. Bernardo Ave., Mountain View, CA 94043, (415)694-0650 uunet!lupine!ed
jcarson@WILKINS.BCM.TMC.EDU (Janet L. Carson) (02/14/90)
>If you want a nice way to allow your X terminals to get started, plus >provide automatic shutdown when the terminal is powered off, you >need XDMCP. The two problems we've been talking about: the need for the user to pick one of several machines to log into, and the need to shutdown all clients, regardless of where they are really running, are not currently solved by XDMCP. (At least this was the impression that I got at the X conference last month...) --Janet Janet L. Carson internet: jcarson@bcm.tmc.edu Baylor College of Medicine uucp: {rutgers,mailrus}!bcm!jcarson
kempff@hppad.HP.COM (John Kempff) (02/17/90)
> / hppad:comp.windows.x / wood@acf4.NYU.EDU (David Wood) / 5:53 pm Feb 9, 1990 / > > > Has anybody written a new xinit type tool for > the X-terminals. I began this and got about half way there > but thought I'd ask around in netland to see if anyone > has already done this. The problem is that xinit always > tries to run a server (or am I mistaken), but these X-terminals > just need to have the .xinitrc (or .xsession) file started > up. Then when the person is done, this knew xinit could do > a killpg() to kill all the clients. That in fact is the > problem I'm experiencing with the X-terminals. If you have > novice user logout of one of these without killing all the > clients they just hang around. Enough said, does anybody > have any comments. Thanks. > > p.s. Perhaps it should be an extension to xinit. > ------------------------------------------------------------------------- > David Wood wood@acf2.nyu.edu > New York University ...!uunet!cmcl2!wood > 212-998-3029 > "Brain. Brain. What is brain?" > Kara the Eymorg, "Spock's Brain", Stardate 5432.3 > ------------------------------------------------------------------------- > ---------- Why use xinit to start sessions on the X terminals. Xdm does the job for me. Before Xdm came out, I tried to modify xinit so that it will work with remote X servers like X terminals. I quickly gave up for two reasons. 1. The version of xinit that I had was written expecting the X server to be running on the same CPU as xinit. The xinit program would startup the server as a child, then verify that it was running by doing an XOpenDisplay() on it. After the server was running, the users .x11start script would also be executed as a child of xinit. It would then immediately wait for a childs death signal, then kill all process associated with both childs. The big problem is that a Xterminal server is not executing locally. There was no easy way of converting this program to detect the death of a remote server. Yes I could have detected the death of the server by polling it, reason 2 (below) came about before I got to writting a robust polling routine. 2. I also ran out of time and Xdm was just made available with X11R4. Xdm will automatically start up the clients on a remote X server after the user logins. Now I can log into any X terminal in our building and have my own personal enviroment. Also when you logoff with xdm, all the clients associated with that X session are also killed. Logging off for me means shutting down one key window, ie a terminal emulator with special colours to indicate that it is the KEY window. Bit of a pain if you accidently kill or logout of that window. What else could I you for :-). The moral of the story is steal xdm. It was written from the ground up expecting remote X servers. John Kempff | ## ## | ######## / ######## X Windows Support Eng. | # # | ####### / ####### Panacom Automation Div. | # | ###### /_ __ ###### H E W L E T T Waterloo, Ontario, Canada | # | ##### / / / / ##### | # # | ##### / / /__/ ##### Email:kempff@hppad.hp.com | ## ## | ###### / ###### P A C K A R D Phone:(519) 886-5320 | | ####### / ####### FAX: (519) 886-8620 | TERMINAL | ########/ ########