[7302] in Athena Bugs

home help back first fref pref prev next nref lref last post

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

home help back first fref pref prev next nref lref last post