[2698] in testers

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

Re: rsaix 7.7E: cleanup bug - maybe ...

daemon@ATHENA.MIT.EDU (cfields@MIT.EDU)
Wed Aug 10 20:36:45 1994

From: cfields@MIT.EDU
Date: Wed, 10 Aug 1994 20:35:50 +0500
To: epeisach@MIT.EDU
Cc: testers@MIT.EDU, jawetzel@MIT.EDU, marc@MIT.EDU, yandros@MIT.EDU

> b) cleanup could do a detach -a (whatever), if and only if no one else
> is logged into the machine.... Assuming that the machine is not hacked
> all should be well.... But what about private machines, like in the sipb
> office and everywhere else - you can't detach things underneath a user
> who may be relying on them...

The cleanup process in question only runs on PUBLIC workstations after
the user on the console logs out. Two things it does are kick everyone
else off the machine and set access_off. So in your scenario, noone
is logged into the machine anyway, and the whole process doesn't apply
to private workstations at all. But essentially the point I'm debating
with Jake is that I don't think we should do a detach -a during this
process.

I think I like (c) too.

Another solution I'm thinking about is a change in the behavior of
attach. If, when you go to attach a locker, something is already
attached on that mountpoint but not by anyone who is in the password
file, detach it first and then attach what was requested there. See
any problems with this? If it's not almost ideal, I haven't figured
out why.

Craig

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