[14698] in Athena Bugs
several bugs with the new release
daemon@ATHENA.MIT.EDU (bdrosen@MIT.EDU)
Thu Sep 26 10:45:17 1996
From: bdrosen@MIT.EDU
To: bugs@MIT.EDU
Date: Thu, 26 Sep 1996 10:45:12 EDT
1.
On a sun setup for remote access (noremote is set ), if a user
tries to log in remotely with standard athena dotfiles they will not
get tokens if they are listed in /etc/group as having more than 13
groups. (I know that not cleaning up /etc/group is a known problem,
but I am not sure that this effect is known)
2.
Also on privatized suns it seems that many processes do not get
killed on logout. Perhaps reactivate should be modified to call
/etc/athena/cleanup -loggedin instead of /etc/athena/cleanup -passwd
if the machine is set up to restrict access to people in /etc/passwd
(check /etc/athena/rc.conf for NOCREATE or NOREMOTE being true).
It seems that the processes that get left behind tend to be
orphans . The standard dotfiles start dash, xterm and mwm (or
WINDOW_MANAGER) in a subschell via ( mwm &) and this causes the process
to be orphaned or the process orphans itself by forking. (xzewd also
gets left behind a lot)
3.
I have reported this before, but have not heard anything about investigating
this problem:
Users often get the following problems on the suns (we get a
fair number of olc questions on this):
ld.so.1: /mit/olc-stock/sun4bin/olc_browser: fatal: libc.so.1.7: can't open file: errno=2
(typing olc answers or typing answers at the olc prompt)
typing: fs flushvol /usr/4lib/*
fixes it. It seems like an AFS bug.
4.
On an sgi setup for remote access, when someone logs off on the console
the reactivate script is run. This detaches all the lockers. This causes
problems for users logged on remotely as this will cause renew to fail
to get new tokens for remote users. (this may be true on the suns as well)
Brett
