Ernest.Hayden@EBay.Sun.COM (Ernest H. Hayden) (05/07/91)
Hans: I don't know if this helps a lot but I noticed that when I started the
tsapd from an interactive shell as follows, /usr/etc/isode/tsapd > & /dev/null,
that I could run ./make test multiple times without it failing. However, when
I tried to run the test against a tsapd that I had started from my rc.local file
(see below) it also failed just as you described.
This was not an upgrade install and so I think that has little to do with it.
I am running the simplest of environments, tsapd was running on the same machine
from which I executed the test. I am running SunOS 4.1.1 Rev B on a
SPARCStation 1.
I suspect that it has something to do with the change Sun made to the rc scripts
when we went from 4.0.3 to 4.1. We did this to satisfy POSIX.1 was related to
the notion of a controlling terminal requirement which was not satisfied in
earlier releases. I don't have a definitive answer yet but you have certainly
aroused my curiosity! If you come up with an answer to this please let the alias
know!
Thanx: Ernest H. Hayden
Systems Engineer
Systems Engineering
Systems Architecture Group
Sun Microsystems Federal, Inc.
MIL06-07
ehh@chanta.EBay.Sun.COM
# ISODE tsap Daemon
#
if [ -f /usr/etc/isode/tsapd ]; then
/usr/etc/isode/tsapd & (echo -n ' tsapd') > /dev/console
fi
#
# ISODE QUIPU Daemon(s)
#
if [ -f /usr/etc/isode/ros.quipu ]; then
(cd /usr/etc/isode/quipu-db; /usr/etc/isode/ros.quipu) &
(echo -n ' quipu') > /dev/console
fiA.Macpherson@stl.stc.co.uk (Andrew Macpherson, Postmaster) (05/07/91)
"Ernest H. Hayden" wrote: | Hans: I don't know if this helps a lot but I noticed that when I | started the tsapd from an interactive shell as follows, | /usr/etc/isode/tsapd > & /dev/null, that I could run ./make test | multiple times without it failing. However, when I tried to run the | test against a tsapd that I had started from my rc.local file (see | below) it also failed just as you described. | I am running the simplest of environments, tsapd was running on the | same machine from which I executed the test. I am running SunOS | 4.1.1 Rev B on a SPARCStation 1. ^^^^^ ^^^^^ The culprit! The semantics of rc processing have changed (as you surmise) enough to break many things which used to work. This is a BUG, but don't expect anyone to fix it. Change your rc script (see below) | I suspect that it has something to do with the change Sun made to | the rc scripts when we went from 4.0.3 to 4.1. We did this to | satisfy POSIX.1 was related to the notion of a controlling terminal | requirement which was not satisfied in earlier releases. I don't | have a definitive answer yet but you have certainly aroused my | curiosity! If you come up with an answer to this please let the | alias know! # ISODE tsap Daemon # if [ -f /usr/etc/isode/tsapd ]; then /usr/etc/isode/tsapd >/dev/null 2>&1; (echo -n ' tsapd') > /dev/console fi # # ISODE QUIPU Daemon(s) # if [ -f /usr/etc/isode/ros.quipu ]; then (cd /usr/etc/isode/quipu-db; /usr/etc/isode/ros.quipu >/dev/null 2>&1) (echo -n ' quipu') > /dev/console fi
A.Macpherson@stl.stc.co.uk (Andrew Macpherson, Postmaster) (05/08/91)
"Ernest H. Hayden" wrote: | Indeed! You have the answer! I tried it and the tsapd stays up | just fine. | | Now .. if I could just understand why it fixes it .... BTW .. do you | believe this is a BUG in Sun's code or somewhere else? ((I won't be | insulted.) | | Thanx: Ernie Hayden (SunFed, SE) | | MIL06-07 | ehh@chanta.EBay.Sun.COM I believe this to be a BUG in Sun`s code, and possibly POSIX (no info here). The problem is that all of a sudden rc is being run with stdout/err attached to /dev/console. This means for isode things that the `autobackgrounding' close, setpgrp, fork sequence is not invoked, and other things are suddenly attached where they were detached. I think it is a BUG, since it is a major change of semantics. Perhaps though, since it is documented, we should call it a feature. :-( It is a major gottcha when making the upgrade from Sunos 4.0.n to 4.1, since things which used to work suddenly stop.
cudep@cu.warwick.ac.uk (Ian Dickinson) (05/08/91)
In article <9105062156.AA01508@chanta.EBay.Sun.COM> Ernest.Hayden@EBay.Sun.com writes: >Hans: I don't know if this helps a lot but I noticed that when I started the >tsapd from an interactive shell as follows, /usr/etc/isode/tsapd > & /dev/null, >that I could run ./make test multiple times without it failing. However, when >I tried to run the test against a tsapd that I had started from my rc.local file >(see below) it also failed just as you described. > >This was not an upgrade install and so I think that has little to do with it. > >I am running the simplest of environments, tsapd was running on the same machine >from which I executed the test. I am running SunOS 4.1.1 Rev B on a >SPARCStation 1. > >I suspect that it has something to do with the change Sun made to the rc scripts >when we went from 4.0.3 to 4.1. We did this to satisfy POSIX.1 was related to >the notion of a controlling terminal requirement which was not satisfied in >earlier releases. I don't have a definitive answer yet but you have certainly >aroused my curiosity! If you come up with an answer to this please let the alias >know! I tried to post something to this effect but it didn't seem to get through. The POSIX session stuff breaks programs that used to disassociate from the terminal in the traditional manner, which may then want to spawn login processes. Sunlink 6.0 X.25 Read Me First points out the fix for 'x29' by starting it using 'setsid -b' which starts a new session and puts it in the background. So to start tsapd on SunOS 4.1 or later you need this in your rc.local (or wherever you put it): # ISODE tsap Daemon # if [ -f /usr/etc/isode/tsapd ]; then setsid -b /usr/etc/isode/tsapd >/dev/null 2>&1 & echo -n " tsap" fi Hope this gets through this time. -- \/ato. Ian Dickinson. / /// Send your dollars, Homeboy, \\\ \ /'\ /`\ vato@warwick.ac.uk ( ((( I'm a Pink Foetus for "Bob" ))) ) /^^^\/^^^\ vato@tardis.cs.ed.ac.uk \ \\`------X.500-Check-me-out-----'// / /TWIN/TEATS\ @c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson / \