Yesterday I posted:
> I'm trying to set up xdm to run the OpenWindows xnews server on our Sun consoles
> and Open Look Window Manager (olwm) and OpenWindows X clients on X terminals
> (PCs running X). I've almost got everything working as I'd like, except for
> shelltool. If I start a shelltool from my .xsession session startup file,
> the shelltool window is opened and displayed, but no shell prompt ever appears.
> I can type to the shelltool window and what I type is echoed, but nothing happens.
> The same problem occurs if I start a shelltool from the olwm menu.
>
> If I look at the .xsession-errors file I see the message:
>
> ttysw-TIOCSPGRP: Interrupted system call
>
> but I don't know if this is coming from the shelltool. Incidentally, I can can
> start xterms instead of shelltools without a problem, but I'd like to get the
> shelltool working.
>
> Any suggestions?
I got many replies pointing me to the /usr/etc/setsid program. The problem is
that xdm starts the session script without a controlling terminal and some
programs (cmdtool, shelltool, dbxtool, emacs xvetool are the ones I know of
so far) require one.
Most of the replies suggested writing a wrapper script around each program that
requires a controlling terminal as in (also see the man page for setsid):
foo# cd /usr/openwin/bin/xview
foo# mv cmdtool .cmdtool
foo# cat > cmdtool
#!/bin/sh
/usr/etc/setsid -b /usr/openwin/bin/xview/.cmdtool "$@"
^D
foo# chmod a+x cmdtool
I took this one step further and ran the user's .xsession script from setsid. This
works fine for programs spawned from the .xsession script. There is still a problem
though; I also start olwm from .xsession as the job which controls the session
(that is, it's the last program started by .xsession and it runs in the foreground).
Programs started from the olwm menu are still lacking a controlling terminal. My
solution to this is to change the invocation of the program in the olwm menu file
to be run from setsid. Does anybody know why the programs launched from olwm
still don't have a controlling terminal?
Thanks for all the replies.
--------------------------------------------------------------------------------
From: Brent Alan Wiese <brent@crick.ssctr.bcm.tmc.edu>
You might try "setsid shelltool". I thought something like that was
suggested in the releas notes.
--------------------------------------------------------------------------------
From: Mark J. McIntosh <mmcintos@sirius.UVic.CA>
This isn't exactly the error I've seen when trying to run shelltools
from MacX, but maybe the solution will help. Shelltool/cmdtool have
the curious requirement for a controlling terminal (and/or be in a
process group). This can be fixed by running the shelltool using
% /usr/etc/setsid shelltool
You can put this invocation in your window manager menus, too.
--------------------------------------------------------------------------------
From: Fergus J. O'Reilly <fergus@capsogeti.fr>
The problem is that the cmdtool/shelltool processes lack a
controlling terminal when descended from the xdm daemon. The
included message below from Sun-Managers deals with a similar
problem.
Of the solutions proposed therein I would recommend number 3.
I.e., use the setsid program in a wrapper around the cmdtool
(shelltool is a link to cmdtool) and dbxtool programs. For
cmdtool, for example, do the following as root:
foo# cd /usr/openwin/bin/xview
foo# mv cmdtool .cmdtool
foo# cat > cmdtool
#!/bin/sh
/usr/etc/setsid -b /usr/openwin/bin/xview/.cmdtool "$@"
^D
foo# chmod a+x cmdtool
A drawback to this solution is that if a user uses olwm's "Save
Workspace" function (usually on the "Utilities" menu) then the
cmdtool will save itself as ".cmdtool" since that is the name
under which it was invoked. I _think_ that this means that it
will fail when olwm next runs the user's .openwin-init.
This problem has cropped up a number of times before on this list
and when you post your summary I suggest that you suggest that it
be put on the Sun-Managers FAQ posting.
Happy Thanksgiving :->
--------- Start of forwarded message -------
From: Peter Koblauch <koblauch@waterloo.hp.com>
To: sun-managers@eecs.nwu.edu
Subject: SUMMARY: xdm start-up affects cmd/shelltool
Date: Mon, 8 Jul 91 13:38:59 EDT
This is a great list.
Thanks to all who replied.
Thanks in particular to:
- - -Leonard E. Sitongia sitongia@ncar.ucar.edu
- - -Bill Hart hart@ocean.ml.csiro.au
- - -Gareth J. Barker gbarker@mph.sm.ucl.ac.uk
- - -Dave Singletary daves@den.mmc.com
- - -Mark Korinek mjk@bru.mayo.edu
Here's an (abbreviated) version of initial mayday:
When started up from the olwm root menu both shelltool/cmdtool
come up but no shell prompt appear. Kbd input is echoed but not
acted upon. Other DeskSet tools work fine.
I think the problem is related to xdm.
xdm is running as session/login manager for HP 700RX terminals
off an SLC host.
is started up from /etc/rc.local
/usr/bin/X11/xdm
or - with similar result
/usr/bin/X11/xdm -nodaemon &
or - with similar result
sh -c "/usr/bin/X11/xdm -nodaemon &"
If started up from console eg sh -c "/usr/bin/X11/xdm -nodaemon&"
instead of from within /etc/rc.local everything is fine,
but really would like to have xdm started automatically during boot.
When tools hang users's .xsessionlog has message
"ttysw-TIOCSPGRP: Interrupted system call"
Both tools may be started up from another window, say xterm,
without any problems, regardless of whether xterm is a decendant of xdm.
Should xdm be started up differently or from another place
(/etc/ttytab?) in order to have a controlling terminal
to pass on to descendants?
ANALYSIS:
Problem is related to some DeskSet clients needing a
controlling terminal passed on from parent.
When started up from (an orphaned) xdm, client doesn't have one.
The clients that I know of are: cmdtool (=shelltool), and dbxtool.
As an aside,- does anybody know of an automated way of starting up xdm
(-nodaemon) during booting so that it still keeps its
controlling terminal?
SOLUTION:
wrap offending tool in setsid. # setsid(8)
eg
1) (from line in .xsession)
setsid -b cmdtool
2) (from line in .openwin-menu)
"Command Tool..." DEFAULT exec setsid cmdtool
or
3) apply instructions given in man setsid(8) to offending client.
This -3)- has has worked fine at my installation for some time.
------- End of forwarded message -------
--------------------------------------------------------------------------------
From: Ken Erickson <ken@kericks.chi.il.us>
This should probably be a FAQ...
Check the man page for 'setsid'. What you need to do is change the
shelltool line to read /usr/etc/setsid -b shelltool. Same for cmdtool.
--------------------------------------------------------------------------------
From: lee@sqlee.sq.com (Liam R. E. Quin)
WARNING
MIT xdm starts OpenWindows as root. Users can ask the OpenWIndows server to
examine/modify files (e.g. /etc/passwd), or even start processes.
Use OpenWindows 3 and the xdm that comes with it if you can.
For the shelltool problem, use setsid to start cmdtool/shelltool -- they're
started without a controlling tty and don't like it.
See the comp.windows.open-look FAQ if you get that newsgroup at your site.
--------------------------------------------------------------------------------
From: mikey@ccs.carleton.ca (Mike McFaul)
You have to run shelltool and cmdtool using /usr/etc/setsid to get
them to work. If you have got NCD xterminals check in the examples
directory for openwindows stuff. Thats where I found it... Also you
have to watch out that the user on the Xterminal doesn't start a
cmdtool as a console grabber (the -C option). When that starts it
steals the console from the user running on the console -- not nice!
I eventually put together a wrapper shell script that checks for an
XDM environment variable and runs the cmdtool/shelltool with setsid if
it needs it. It's below...
Supposedly the filemgr program also needs this kind of wrapper but I
have yet to get it (filemgr) to work properly...
#!/bin/sh
#
if [ "${XDM-notset}" ]; then
exec $OPENWINHOME/bin/xview/cmd/cmdtool $*
else
for PARAMETER do
if [ "-C" != "$PARAMETER" ]; then
NEW_PARAMS="$NEW_PARAMS $PARAMETER"
fi
done
exec /usr/etc/setsid -b $OPENWINHOME/bin/xview/cmd/cmdtool $NEW_PARAMS
fi
--------------------------------------------------------------------------------
From: "Dr Gareth J. Barker" <gbarker@mph.sm.ucl.ac.uk>
You need to user a setsid 'wrapper'. - See setsid man page (actually this
doesn't really explain anything so it may be best to just except that
it's a piece of magic :-(. Try:
/usr/etc/setsid $OPENWINHOME/bin/xview/shelltool
--------------------------------------------------------------------------------
From: randy@ncbi.nlm.nih.gov (Rand S. Huntzinger)
Run the shelltool using setsid. [Ie. use "setsid shelltool" instead of
simply "shelltool"]. I think I used the -b flag, but I don't know if it is
needed or not. Check out the manual page on it.
--------------------------------------------------------------------------------
-- Todd Pfaff \ Internet: todd@flex.eng.mcmaster.ca Dept. of Mechanical Engineering \ Voice: (416) 525-9140 x2902 McMaster University \ FAX: (416) 572-7944 Hamilton, Ontario, CANADA L8S 4L7 \
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:16 CDT