[OpenAFS-port-darwin] Installer hang, 1.5.15 for MacOS 10

[Garance A Drosihn]

[I sent this to the wrong place the first time.  Let me try it again!]

[]   I went to install OpenAFS 1.5.15 on top of a MacOS/Intel system
[]   which already had OpenAFS 1.4.2  installed on it.  MacOS 10.4.8
[]   on a 1.66 GHz Intel Core-duo Mac-Mini.
[]
[]   It hung.  The installer itself hung, very early in the install.
[]   Well, it kept running, but the progress bar wasn't moving.  I left
[]   it there for over 10 minutes without it moving more than 1/4-inch.
[]
[]   I tried to quit the installer, and the installer said it couldn't
[]   quit because it was in the middle of installing things.  I tried to
[]   do a force-quit, but the system's force-quit window wouldn't come
[]   up!  (I could select it from the apple menu, multiple times, but the
[]   dialog would never pop up).  I selected 'restart...' from the apple
[]   menu, and again nothing happened.  From a terminal window, I did a
[]   'sudo shutdown -r now Installer Hung', and the shutdown started,
[]   but then the shutdown itself hung.  It ended up that I had to hold
[]   down the power-button for a few seconds, and thus force a power-off.
[]
[]   The Mac booted back up okay, and was still running 1.4.2. So this
[]   time I got myself better prepared for any trouble, and ran the
[]   installer again.  This time the installer worked fine.  I rebooted,
[]   and the new version of OpenAFS came up fine.  No trouble at all.
[]
[]   I admit that as a bug report this email is pretty useless.  I can
[]   only come up with one vague idea for what might have caused the
[]   problem.  It occurs to me that at the time that I did the first
[]   update, I had Terminal.app running, and it had several windows
[]   which were 'cd'-ed into various directories in AFS space.  Perhaps
[]   that prevented AFS 1.4.2 from shutting down?

Jeffrey Hutzelman happened to be on the receiving end of my first
   attempt to send that, and he replied:
>
>In fact, that is the case.  A terminal window whose current directory
>in AFS is using the AFS filesystem, which prevents it from being
>unmounted. There's not a lot that can be done about this -- you'd
>hardly be happy if the installer started killing off random processes
>in order to eliminate anything using the filesystem.

Well, I wasn't exactly thrilled with the above behavior, either!  :-)

The initial "Important Information" screen (in the installer-package)
mentions that the user should reboot after the install is done.  So,
it is already true that the person doing the install should realize
that they soon might have to quit any active applications.

>However, it would probably be good if the installer were more robust
>in this situation, detecting the problem and either aborting the
>install or arranging for the new version to be used on the next
>restart.

For the situation I was in, it would have helped just to have the
"Important info" panel tell me that I should close any applications
which have AFS files open.  All of my terminal sessions were just left
over from two days earlier, and I could have easily quit Terminal if
it had occurred to me that it might cause a problem.  Obviously this
is not a complete fix for all cases, but it has the advantage of being
very little work.  :-)

While it would help if the installer could detect the problem itself, I
agree that the installer should not be blasting away processes.  What if
the home-directory of the user is in AFS space?  Or if the installer
(the dmg file itself) was?  I don't know if the installer should try to
detect that it cannot shutdown AFS, or if it should just assume that the
user will always have to reboot to bring in the new AFS, and force a
reboot whenever upgrading AFS.  A forced-reboot would be annoying behavior
if we were upgrading a plain user-application, but maybe we should go that
route given that we're upgrading something as major as filesystem-support.

The nicer, more-work solution would be to do something like have a pre-
install script that does "lsof | grep ' /afs/'", and then listed to the
user any processes it found.  Then provide an option (perhaps as a custom-
install selection?) that a user can go with if they simply cannot kill
all the processes which have a file open in AFS space.

Anyone have some other solutions to suggest?

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu