SCIENTIFIC-LINUX-USERS Archives

August 2006

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Wed, 2 Aug 2006 19:53:34 +0200
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (76 lines)
Hi All,

there are problems with the latest firefox if user home directories
reside in AFS. See

  https://grand.central.org/rt/index.html?q=31818

and

  https://bugzilla.mozilla.org/show_bug.cgi?id=318801

Short story: there were locking changes that seem to require 100% POSIX 
compliant behaviour of the filesystem ~/.mozilla resides on. At least
if ~ resides in AFS space, a lock on a file called ".parentlock" in the
active profile directory is not released reliably when firefox exits,
leading to a dialog box saying something to the effect of "some firefox
process is already running, and you have to get rid of it before you
can start another one", even if there's definitely no such process 
accessing the home directory on any system.

AFS users who haven't seen this yet can simply remove the "k" bit from
their firefox profile directory to make this 100% reproducible. Otherwise,
the problem shows up randomly only.

The URLs above prove that both the OpenAFS project (NB the problem occurs 
with 1.2.13 clients on SL3 as well as 1.4.1 clients on SL4, and to my 
knowledge hasn't been fixed in any OpenAFS release including the 1.5 
development branch) and the mozilla project have known about the problem 
for 8 months, and it still exists. In addition, it seems to affect 
thunderbird as well, and at least NFS and CIFS besides AFS.

Hence I guess we're not the only site in need of a fix or at least a 
workaround.

I can imagine dealing with the problem in the following ways:

 1) Try the patch from comment #29 to the bugzilla.mozilla.org bug
    (use symlinks instead of fcntl() for "locking"). Maybe make it 
    unconditional and thus much simpler.
 2) Educate all my users how to delete the .parentlock file if necessary.
 3) Tell all my users to make
      ~/.mozilla/<whatever their profile>/.parentlock 
    a symlink to a file in /tmp.
 4) Do the same transparently with some scripting in one of the
    firefox wrappers, or using the "init.d" functionality provided
    by one of them, creating the tmp-file in a secure fashion if
    needed.

The last one is probably best, but it's also a bit of work. The script
would have to do something like this:

 o find all .parentlock files in ~/.mozilla
   (since we don;t know which profile is going to be used)
 o if they're symlinks, and point to some file in /tmp, and that
   file exists and is owned by $USER, do nothing
 o if they're symlinks, point to some file in /tmp, and that
   file exists but is not owned by USER, OR
     o if they're not symlinks OR
     o if they don't point into /tmp, delete (rename?) them
   create a unique file in /tmp and replace them by symlinks to those


I sincerely hope someone on this list has a better and more failsafe 
idea...

How are other AFS sites dealing with this? Jarek, Jan, Connie, Troy,..?

Cheers,
	Stephan

-- 
Stephan Wiesand
  DESY - DV -                     Phone:   +49 33762 7 7370
  Platanenallee 6                 Fax:     +49 33762 7 7216
  15738 Zeuthen, Germany

ATOM RSS1 RSS2