[4073] in testers

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

8.3.2 irix 6.5 attach failures

daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Thu May 20 18:15:31 1999

Message-Id: <199905202215.SAA03499@speaker-for-the-dead.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: testers@MIT.EDU
Date: Thu, 20 May 1999 18:15:18 EDT


I just ran into a colossal chain of failures in attach.  I updated my
indy to 8.3.2 a couple of days ago, and was about to update it to 8.3
when I ran into problems, so it's possible that some of these have
been fixed.

I've talked this through with Dan so this message is mostly for the
record.

Sequence of events: 

1) deliverator running 8.2 with many lockers attached and locked,
   including mkserv, and the attachtab in a non-default location

2) I take 8.3.2, which fails to notice my non-default location
   attachtab (which I'd already decided to punt for 8.3).
   the newly converted attachtab says nothing is attached

3) The mkserv part of the update occurs after a reboot, and the
   attachandrun mkserv script attaches te mkserv locker.  Well,
   presumably, it just puts it in the attachtab, since the link 
   in /mit already existed.

4) My .private script gets run.  in its attempt to put things into a
   sane stat it made things worse.  It rm'd my old attachtab, and
   everything under /mit (including mkserv).

   Then it attach -locked a bunch of lockers, including mkserv.
   However, since mkserv was already in the attachtab as attached
   attach just marked it as locked, and didn't notice that it wasn't
   actually attached
   
*) I'm not sure if it's a bug report or feature request, but it would
   be nice if attach would detect this case and do something more sane.
   Admittedly, attach has never really dealt with this sort of corruption.

5) after rebooting, I try to take 8.3.3, but fail, because it can't
   find mkserv because the locker claims to be attached but isn't.

6) I try to attach mkserv and get:
   Error while subscribing:
   You have no tickets cached.

*) Dan says this is a known bug

7) I figure out that mkserv isn't actually attached.

8) I detach -O mkserv

8) /mit/attachtab/mountpoint/_=mit_=mkserv
   becomes a zero-length file

*) I believe this is a bug, because of 9

9) running attach with no options coredumps

*) This is a known bug, but now we know at least one way to get into
   the 'impossible' state for having an empty mountpoint file.


There is a behavior change between the old attach and the new one.  If
you try to attach the bitbucket locker, and /mit/bitbucket already
exists, the old attach will succeed, and the new one will fail.  I
don't think this is too bad, since detach seems to cleanup the
mountpoint, even if somethign else (eg a reboot) did the unmount.

	Jonathon

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