Hallo,
thanks. Simple and effective. Folks have learned to check for the lock
file, but hardly expect the hidden one. I think I'm going to roll this out
as /usr/lib/firefox-1.5.0.5/init.d/S01parentlock .
Thanks again,
Stephan
On Thu, 3 Aug 2006, Gerd Heide wrote:
> Hallo,
>
> my workaround is, included in /usr/bin/firefox:
>
> [ -e $HOME/.mozilla/firefox/profiles.ini ] &&
> for i in $(grep Name= $HOME/.mozilla/firefox/profiles.ini | sed s/Name=//)
> do
> [ ! -L $HOME/.mozilla/firefox/*.$i/lock -a -e $HOME/.mozilla/firefox/*.$i/.parentlock ] &&
> rm -f $HOME/.mozilla/firefox/*.$i/.parentlock
> done
>
>
> On Wed, 2 Aug 2006, Stephan Wiesand wrote:
>
>> Date: Wed, 02 Aug 2006 19:53:34 +0200 (CEST)
>> From: Stephan Wiesand <[log in to unmask]>
>> To: <[log in to unmask]>
>> Subject: firefox (thunderbird) 1.5 problems with ~ in AFS (NFS, CIFS...)
>>
>> 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
|