[7302] in Athena Bugs
Re: Strange behavior when logging in
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Mar 13 11:14:39 1991
Date: Wed, 13 Mar 91 11:14:00 -0500
To: bugs@MIT.EDU
Cc: amgreene@MIT.EDU, lnp@MIT.EDU
Cc: athena-ws@MIT.EDU
In-Reply-To: bugs[7301]
From: Richard Basch <basch@MIT.EDU>
Subject: re: Strange behavior when logging in
From: lnp@ATHENA.MIT.EDU
Date: Wed, 13 Mar 91 10:08:57 -0500
To: bugs@ATHENA.MIT.EDU
> Sometimes (but not reproducably) when I log in, I lose my tickets
> and tokens (or maybe I never had them).
I've had that happen too and my dot files are standard. Also, my
machine is a VS3100 running 7.2P
Could the flushing /tmp upon deactivation be in progress at the time
of logging in?? Supposedly that timing problem was fixed, but I don't
think it was completely fixed on the VS3100's.
-lnp
The timing has NOT been fixed. Unless we opt to create an /etc/nologin
during the reactivation, the problem becomes a difficult one of IPC
(inter-process communication). Do we really wish to complicate the
logic to add this to indicate to all the possible "login" programs that
there is an ongoing reactivation and that it may interfere with the
login process?
This is a perfect example of how compartmentalization of data within
UNIX processes and its children poses a problem for session management;
the same problem applies to the logout situation:
- Remote logins and local logins... one had control of the password file
and it is the responsibility of the login that added you to the password
file to remove you. However, multiple login processes, if not exited
in the reverse order that they were started may cause a removal of an
entry that will later cause other problems.
- Communication of all processes to the session managers that they no
longer require the use of the session manager... (see the "lore" and
"athena-ws" discuss meetings about the xmh and logout-alias problems)
Even worse... as we move towards vendor OS, and lack of source for some
of these systems, we will be unable to add the IPC to the various
programs in order to fix the problem. So, before considering this
approach of modifying all the programs, an attempt must be made to see
if a portable paradigm is achievable.
-R